Как посмотреть токен в браузере
Чтобы воспользоваться API токена регистрации, пользователям необходимо пройти авторизацию, как описано в этой статье, и получить токен доступа.
Вызов API
Как получить список всех токенов регистрации для выбранного аккаунта
Чтобы получить список всех токенов регистрации Chrome для отдельного аккаунта в конкретном организационном подразделении, используйте приведенный ниже запрос GET, добавив в него данные для авторизации, как описано в соответствующем разделе.
Примечание. Для удобства восприятия пример кода разделен на строки с помощью переносов.
В приведенной ниже таблице представлены все значимые параметры, которые можно использовать в таком запросе.
| Параметр | Обязательный | Тип | Описание |
|---|---|---|---|
| orgUnitPath | нет | строка | Выводит список токенов регистрации, созданных в конкретном организационном подразделении. Если поле не заполнено, выводятся все токены регистрации этого клиента. |
| pageSize | нет | целое число | Максимальное число результатов на странице. Значение не должно превышать 100 (задано по умолчанию). |
| pageToken | нет | строка | Для перехода к следующей странице результатов запроса используется параметр pageToken. Значение параметра pageToken в последующем запросе соответствует значению nextPageToken в данных, полученных в ответ на предыдущий запрос. Примечание. В запросах с полем page_token значения полей query и org_unit_path должны соответствовать значениям этих полей в запросе, который использовался для генерации значения в page_token. |
| query | нет | строка | Строка поиска, позволяющая фильтровать полученный список токенов. Формат языка запросов для фильтрации списка результатов описан ниже, в разделе "Язык запросов фильтрации данных". |
Пример
Пример запроса
Ответ JSON
Язык запросов фильтрации данных
Если при запросе списка используется параметр "query", каждое значение в этом запросе будет действительным только при наличии соответствия в одном из последующих параметров. Если в запросе отсутствуют операторы (поля), в результатах будут представлены все найденные токены регистрации.
Чтобы уточнить параметры поиска, можно указать следующие поля:
| Поле | Описание |
|---|---|
| device_type | Тип устройств, для которых используются токены регистрации. В настоящее время поддерживается только значение CHROME_BROWSER. |
| token_state | Состояние токена регистрации. Поддерживаемые значения: REVOKED, ACTIVE, EXPIRED. |
Как создать токен регистрации
Чтобы создать в организационном подразделении токен регистрации Chrome, используйте приведенный ниже запрос POST, добавив в него данные для авторизации, как описано в соответствующем разделе.
Примечание. Для удобства восприятия пример кода разделен на строки с помощью переносов.
В приведенной ниже таблице представлены все значимые параметры, которые можно использовать в таком запросе.
| Параметр | Обязательный | Тип | Описание |
|---|---|---|---|
| expire_time | нет | строка | Срок действия созданного токена регистрации. Используйте следующий формат: гггг-ММ-ддTчч:мм:ссZ. Если значение в этом поле не задано, токен регистрации действует, пока не будет отозван пользователем. |
| org_unit_path | нет | строка | Организационное подразделение, для которого создается токен регистрации. Если значение в этом поле не задано, токен регистрации создается для корневого организационного подразделения. |
| token_type | да | строка | Тип устройства Chrome, для которого создается токен регистрации. В настоящее время поддерживается только значение "CHROME_BROWSER". |
| ttl | нет | строка | Период действия созданного токена регистрации: указывается в секундах с суффиксом "s". Например, если токен должен действовать в течение 1 часа, в поле указывается значение "3600s". Если значение в этом поле не задано, токен регистрации действует, пока не будет отозван пользователем. |
Пример
Пример запроса
POST https://www.googleapis.com/admin/directory/v1.1beta1/customer/my_customer/chrome/enrollmentTokens
"token_type": "CHROME_BROWSER",
"org_unit_path": "/org-unit-path",
"expire_time": "2021-04-30T19:22:44Z",
>
Ответ JSON
Как отозвать токен регистрации
Чтобы отозвать токен регистрации, используйте приведенный ниже запрос POST, добавив в него данные для авторизации, как описано в соответствующем разделе.
Примечание. Для удобства восприятия пример кода разделен на строки с помощью переносов.
Просидев несколько дней листая страницы гугла, я понимаю, что скорее всего этот вопрос будет ориентирован на самых опытных пользователей Android, так как ни одной работающей строчки кода мне не удалось найти.
Нужно имплементировать Google-кнопку в приложении. Процесс, пошагово описан в этой официальной статье, но там всё заканчивается на том, что user может получить токен от Google. и всё.
И ни слова больше о том, что с ним делать и как его проверить на сервере.
Если судить по веб-версии этой же имплементации, то там после удачной аутентификации пользователю возвращается JSON-файл примерно с таким содержанием
В нём есть всё, что нужно: и тип, и refresh, и время действия, и сам токен.
В случае же, когда нужно получить такие данные на Android, тут два варианта: либо я не совсем понимаю как это правильно должно работать (так как в библиотеке просто нет методов для получения этих данных), либо это просто невозможно (во что я верю меньше).
Если кому-то уже приходилось делать вход через Google у себя в приложении, расскажите, пожалуйста, как это должно работать?
UPD №1
Как мы можем обеспечить безопасность данных пользователя, если кто-то украдёт токен?
Я так понимаю, что для этого у токена есть expiry , и по его окончанию токен перестает быть действительным (то есть даже если он будет украден, то не будет действителен дольше, чем указано) и при следующем запросе к серверу, потребуется его обновить.
И тут для того, чтоб не заставлять пользователя опять проходить процесс аутентификации, нам на помощь приходит refresh_token . Мы его отправляем на Google API, Google смотрит — видит, что это действительно его refresh token и отправляет нам в ответ новенький токен, с которым опять идём на сервер.
Сервер видит, что user действительно тот, за кого себя выдаёт — работаем дальше.
Я так понимаю, это так должно работать? По крайней мере на вебе это так работает.
Но вопрос: нужно ли получать токен на стороне клиента или на стороне сервера? И кто его должен обновлять: сервер или клиент?
UPD №2
В итоге суть вопроса сводиться к тому, как обеспечить безопасность данных пользователя? Так как, насколько я понимаю, именно для этого нужены и access_token , и tokenId , и refresh_token — всё это было придумано для безопасности и аутентификации, выдачи прав на то или иное проверенному пользователю.
Я так понимаю, что к каждому запросу на сервер прикрепляется этот токен, и сервер идентифицирует тот ли это user, или нет.
Как должно это работать? Должен ли клиент прикреплять Google-токен ко всем запросам к серверу? Должен ли клиент обновлять его каждый раз, когда время его жизни заканчивается? Или это делает сервер? Или нужно сгенерировать свой токен и работать с ним?
Аутентификация(authentication, от греч. αὐθεντικός [authentikos] – реальный, подлинный; от αὐθέντης [authentes] – автор) - это процесс проверки учётных данных пользователя (логин/пароль). Проверка подлинности пользователя путём сравнения введённого им логина/пароля с данными сохранёнными в базе данных.
Авторизация(authorization — разрешение, уполномочивание) - это проверка прав пользователя на доступ к определенным ресурсам.
Например после аутентификации юзер sasha получает право обращатся и получать от ресурса "super.com/vip" некие данные. Во время обращения юзера sasha к ресурсу vip система авторизации проверит имеет ли право юзер обращатся к этому ресурсу (проще говоря переходить по неким разрешенным ссылкам)
Собственно п.5 и есть процесс авторизации.
Дабы не путатся с понятиями Authentication/Authorization можно использовать псевдонимы checkPassword/checkAccess(я так сделал в своей API)
JSON Web Token (JWT) — содержит три блока, разделенных точками: заголовок(header), набор полей (payload) и сигнатуру. Первые два блока представлены в JSON-формате и дополнительно закодированы в формат base64. Набор полей содержит произвольные пары имя/значения, притом стандарт JWT определяет несколько зарезервированных имен (iss, aud, exp и другие). Сигнатура может генерироваться при помощи и симметричных алгоритмов шифрования, и асимметричных. Кроме того, существует отдельный стандарт, отписывающий формат зашифрованного JWT-токена.
Пример подписанного JWT токена (после декодирования 1 и 2 блоков):
Токены предоставляют собой средство авторизации для каждого запроса от клиента к серверу. Токены(и соотвественно сигнатура токена) генерируются на сервере основываясь на секретном ключе(который хранится на сервере) и payload'e. Токен в итоге хранится на клиенте и используется при необходимости авторизации како-го либо запроса. Такое решение отлично подходит при разработке SPA.
При попытке хакером подменить данные в header'ре или payload'е, токен cтанет не валидным, поскольку сигнатура не будет соответствовать изначальным значениям. А возможность сгенерировать новую сигнатуру у хакера отсутствует, поскольку секретный ключ для зашифровки лежит на сервере.
access token - используется для авторизации запросов и хранения дополнительной информации о пользователе (аля user_id, user_role или еще что либо, эту информацию также называет payload). Сам токен храним не в localStorage как это обычно делают, а в памяти клиентского приложения.
refresh token - выдается сервером по результам успешной аутентификации и используется для получения нового access token'a и обновления refresh token'a
Каждый токен имеет свой срок жизни, например access: 30мин, refresh: 60дней
Поскольку токены это не зашифрованная информация крайне не рекомендуется хранить в них какую либо sensitive data (passwords, payment credentials, etc. )
Роль рефреш токенов и зачем их хранить в БД. Рефреш на сервере хранится для учета доступа и инвалидации краденых токенов. Таким образом сервер наверняка знает о клиентах которым стоит доверять(кому позволено авторизоваться). Если не хранить рефреш токен в БД то велика вероятность того что токены будут бесконтрольно гулять по рукам злоумышленников. Для отслеживания которых нам прийдется заводить черный список и периодически чистить его от просроченных. В место этого мы храним лимитированный список белых токенов для каждого юзера отдельно и в случае кражи у нас уже есть механизм противодействия(описано ниже).
Схема создания/использования токенов (api/auth/login):
- Пользователь логинится в приложении, передавая логин/пароль на сервер
- Сервер проверят подлинность логина/пароля, в случае удачи генерирует и отправляет клиенту два токена(access, refresh) и время смерти access token'а ( expires_in поле, в unix timestamp). Также в payloadrefresh token'a добавляется user_id
- Клиент сохраняет токены и время смерти access token'а, используя access token для последующей авторизации запросов
- Перед каждым запросом клиент предварительно проверяет время жизни access token'а (из expires_in )и если оно истекло использует refresh token чтобы обновить ОБА токена и продолжает использовать новый access token
Схема рефреша токенов (одна сессия/устройство, api/auth/refresh-tokens):
- Клиент(фронтенд) проверяет перед запросом не истекло ли время жизни access token'на
- Если истекло клиент отправляет на auth/refresh-token URL refresh token
- Сервер берет user_id из payload'arefresh token'a по нему ищет в БД запись данного юзера и достает из него refresh token
- Сравнивает refresh token клиента с refresh token'ом найденным в БД
- Проверяет валидность и срок действия refresh token'а
- В случае успеха сервер:
- Создает и перезаписывает refresh token в БД
- Создает новый access token
- Отправляет оба токена и новый expires_in access token'а клиенту
С такой схемой юзер сможет быть залогинен только на одном устройстве. Тоесть в любом случае при смене устройства ему придется логинится заново.
Если рассматривать возможность аутентификации на более чем одном девайсе/браузере(мульти сессии): необходимо хранить весь список валидных рефреш токенов юзера. Если юзер авторизовался более чем на ±10ти устройствах(что есть весьма подозрительно), автоматически инвалидоровать все рефреш токены кроме текущего и отправлять email с security уведомлением. Как вариант список токенов можно хранить в jsonb(если используется PostgreSQL).
Схема рефреша токенов (мульти сессии/несколько устройств, api/auth/refresh-tokens):
Для использования возможности аутентификации на более чем одном девайсе необходимо хранить все рефреш токены по каждому юзеру. Я этот список храню в записи юзера в виде JSONB. Во время кажого процесса логина необходимо добавлять IP/Fingerprint пользователя-владельца логина/пароля в белый список.
- Клиент(фронтенд) проверяет перед запросом не истекло ли время жизни access token'на
- Если истекло клиент отправляет на auth/refresh-token URL refresh token
- Сервер берет user_id из payload'arefresh token'a по нему ищет в БД запись данного юзера
- Проверяет IP юзера запрашиваемого обновление токенов с белым списком, если все успешно достает refresh token из записи в refreshTokensMap
- Если IP юзера отсутствует в белом списке, редиректит на страницу логина
- Удаляет старый рефреш токен
- Проверяет количество уже существующих решфреш токенов.
- Если их больше 10, удаляет все токены, создает новый и запиывает его в БД.
- Если их меньше 10 просто создает и записывает новый в БД.
- Создает новый access token
- Отправляет оба токена и новый expires_in access token'а клиенту
Таким образом если юзер залогинился на пяти устройствах, рефреш токены будут постоянно обновлятся и все счастливы. Но если с аккаунтом юзера начнут производить подозрительные действия(попытаются залогинится более чем на 10ти устройствах) система сбросит все сессии(рефреш токены) кроме последней.
Как дополнительная мера можно вообще заблокировать данного юзера при попытке залогинится более чем на 10ти устройствах. С возможностью разблокировки только через email. Но в этом случае нам необходимо будет во время каждого рефреша проверять список токенов на наличие мертвых(не валидных).
В момент рефреша то есть обновления access token'a обновляются ОБА токена. Но как же refresh token может сам себя обновить, он ведь создается только после успешной аунтефикации ? refresh token в момент рефреша сравнивает себя с тем refresh token'ом который лежит в БД и вслучае успеха, а также если у него не истек срок, система рефрешит токены. Внимание при обновлении refresh token'a продливается также и его срок жизни.
Возникает вопрос зачем refresh token'y срок жизни, если он обновляется каждый раз при обновлении access token'a ? Это сделано на случай если юзер будет в офлайне более 60 дней, тогда прийдется заново вбить логин/пароль.
В случае кражи токенов (когда когда юзер логинится только с одного устройства: одна сессия):
- Хакер воспользовался access token'ом
- Закончилось время жизни access token'на
- Клиент хакера отправляет refresh token
- Хакер получает новую пару токенов
- На сервере создается новая пара токенов("от хакера")
- Юзер пробует зайти на сервер >> обнаруживается что токены невалидны
- Сервер перенаправляет юзера на форму аутентификации
- Юзер вводит логин/пароль
- Создается новая пара токенов >> пара токенов "от хакера" становится не валидна
Проблема: Поскольку refresh token продлевает срок своей жизни каждый раз при рефреше токенов >> хакер пользуется токенами до тех пор пока юзер не залогинится.
В случае кражи токенов (когда когда юзер логинится с нескольких устройства: мульти сессии):
Во время кажого процесса логина необходимо добавлять IP/Fingerprint пользователя-владельца логина/пароля в белый список. Таким образом при каждой попытке зайти с новой точки доступа придется перелогиниватся.
В настоящее время киберпреступность стала проблемой мирового уровня. Например, Дмитрий Самарцев, директор BI.ZONE в сфере кибербезопасности привёл на Всемирном экономическом форуме следующие цифры. В 2018 году ущерб мировой экономики от киберпреступности составил по его словам 1.5 триллиона долларов. В 2022 году прогнозируются потери уже в 8 триллионов, а в 2030 ущерб от киберпреступлений может превысить 90 триллионов долларов. Чтобы уменьшить потери от киберпреступлений, необходимо совершенствовать методы обеспечения безопасности пользователей. В настоящее время существует множество методов аутентификации и авторизации, которые помогают реализовать надежную стратегию безопасности. Среди них многие эксперты выделяют в качестве лучшей авторизацию на основе токенов.
До появления токена авторизации повсеместно использовалась система паролей и серверов. Сейчас эта система всё ещё остаётся актуальной из-за своей простоты и доступности. Используемые традиционные методы гарантируют пользователям возможность получить доступ к их данным в любое время. Это не всегда эффективно.
Рассмотрим эту систему. Как правило, идеология их применения базируется на следующих принципах:
Осуществляется генерация аккаунтов, т.е. люди придумывают сочетание букв, цифр или любых известных символов, которые станут логином и паролем.
Для осуществления возможности входа на сервер, пользователю требуется сохранять эту уникальную комбинацию и всегда иметь к ней доступ.
При необходимость заново подключиться к серверу и авторизироваться под своим аккаунтом, пользователю требуется заново вводить пароль и логин.
Кража паролей – это далеко не уникальное событие. Один из первых задокументированных подобных случаев произошел еще в 1962 году. Людям не просто запоминать разные комбинации символов, поэтому они часто записывают все свои пароли на бумаге, используют один и тот же вариант в нескольких местах, лишь слегка модифицируют с помощью добавления символов или изменением регистра некий старый пароль, чтобы использовать его в новом месте, из-за чего два пароля становятся крайне схожи. Логины по той же причине часто делаются одинаковые, идентичные.
Помимо опасности кражи данных и сложности с хранением информации, пароли также требуют проверки подлинности сервера, что увеличивает нагрузку на память. Каждый раз, когда пользователь входит в систему, компьютер создает запись транзакции.
Авторизация токенов – это система, работающая совершенно иначе. С помощью авторизации токенов вторичная служба проверяет запрос сервера. Когда проверка завершена, сервер выдает токен и отвечает на запрос. У пользователя все еще может быть один пароль для запоминания, но токен предлагает другую форму доступа, которую гораздо труднее украсть или преодолеть. И запись сеанса не занимает места на сервере. По сути токен авторизации - это устройство, предназначенное для обеспечения информационной безопасности пользователя, также используется для идентификации его владельца. Как правило, это физическое устройство, используемое для упрощения аутентификации.
Типы токенов авторизации
Токены авторизации различаются по типам. Рассмотрим их:
Устройства, которые необходимо подключить физически. Например: ключи, диски и тому подобные. Тот, кто когда-либо использовал USB-устройство или смарт-карту для входа в систему, сталкивался с подключенным токеном.
Устройства, которые находятся достаточно близко к серверу, чтобы установить с ним соединение, но оно не подключаются физически. Примером такого типа токенов может служить "magic ring" от компании Microsoft.
устройства, которые могут взаимодействовать с сервером на больших расстояниях.
Во всех трех случаях пользователь должен что-то сделать, чтобы запустить процесс. Например, ввести пароль или ответить на вопрос. Но даже когда эти шаги совершаются без ошибок, доступ без токена получить невозможно.
Процесс токен авторизации
Авторизация с помощью токена происходит следующим образом. Сначала человек запрашивает доступ к серверу или защищенному ресурсу. Запрос обычно включает в себя ввод логина и пароля. Затем сервер определяет, может ли пользователь получить доступ. После этого сервер взаимодействует с устройством: ключ, телефон, USB или что-то ещё. После проверки сервер выдает токен и отправляет пользователю. Токен находится в браузере, пока работа продолжается. Если пользователь попытается посетить другую часть сервера, токен опять связывается с ним. Доступ предоставляется или, наоборот, запрещается на основе выданного токена.
Администраторы устанавливают ограничения на токены. Можно разрешить одноразовый токен, который немедленно уничтожается, когда человек выходит из системы. Иногда устанавливается маркер на самоуничтожение в конце определенного периода времени.
Что такое аутентификация на основе токенов?
Аутентификация на основе токенов - это один из многих методов веб-аутентификации, используемых для обеспечения безопасности процесса проверки. Существует аутентификация по паролю, по биометрии. Хотя каждый метод аутентификации уникален, все методы можно разделить на 3 категории:
аутентификация по паролю (обычное запоминание комбинации символов)
аутентификация по биометрии (отпечаток пальца, сканирование сетчатки глаза, FaceID)
Аутентификация токенов требует, чтобы пользователи получили сгенерированный компьютером код (или токен), прежде чем им будет предоставлен доступ в сеть. Аутентификация токенов обычно используется в сочетании с аутентификацией паролей для дополнительного уровня безопасности (двухфакторная аутентификация (2FA)). Если злоумышленник успешно реализует атаку грубой силы, чтобы получить пароль, ему придется обойти также уровень аутентификации токенов. Без доступа к токену получить доступ к сети становится труднее. Этот дополнительный уровень отпугивает злоумышленников и может спасти сети от потенциально катастрофических нарушений.
Как токены работают?
Во многих случаях токены создаются с помощью донглов или брелоков, которые генерируют новый токен аутентификации каждые 60 секунд в соответствии с заданным алгоритмом. Из-за мощности этих аппаратных устройств пользователи должны постоянно держать их в безопасности, чтобы они не попали в чужие руки. Таким образом, члены команды должны отказаться от своего ключа или брелока, если команда распадается.
Хотя эти традиционные системы аутентификации токенов все еще действуют сегодня, увеличение количества смартфонов сделал аутентификацию на основе токенов проще, чем когда-либо. Смартфоны теперь могут быть дополнены, чтобы служить генераторами кодов, предоставляя конечным пользователям коды безопасности, необходимые для получения доступа к их сети в любой момент времени. В процессе входа в систему пользователи получают криптографически безопасный одноразовый код доступа, который ограничен по времени 30 или 60 секундами, в зависимости от настроек на стороне сервера. Эти мягкие токены генерируются либо приложением-аутентификатором на устройстве, либо отправляются по запросу через SMS.
Появление аутентификации на основе токенов смартфонов означает, что у большинства сотрудников уже есть оборудование для генерации кодов. В результате затраты на внедрение и обучение персонала сведены к минимуму, что делает эту форму аутентификации на основе токенов удобным и экономически выгодным вариантом для многих компаний.
Безопасно ли использование токенов?
По мере роста киберпреступности и усложнение методов атак должны совершенствоваться методы и политика защиты. Из-за растущего использования атак “грубой силой”, перебора по словарю и фишинга для захвата учетных данных пользователей становится совершенно очевидно, что аутентификации по паролю уже недостаточно, чтобы противостоять злоумышленникам.
Аутентификация на основе токенов, когда она используется в тандеме с другими методами аутентификации, создает барьер 2FA, предназначенный для того, чтобы остановить даже самого продвинутого хакера. Поскольку токены могут быть получены только с устройства, которое их производит - будь то брелок или смартфон, системы авторизации токенов считаются очень безопасными и эффективными.
Но, несмотря на множество преимуществ, связанных с платформой токенов, всегда остается небольшой риск. Конечно, токены на базе смартфонов невероятно удобны в использовании, но смартфоны также представляют собой потенциальные уязвимости. Токены, отправленные в виде текстов, более рискованны, потому что их можно перехватить во время передачи. Как и в случае с другими аппаратными устройствами, смартфоны также могут быть потеряны или украдены и оказаться в руках злоумышленников.
Рекомендации по аутентификации на основе токенов
Реализация надежной стратегии аутентификации имеет решающее значение, когда речь идет о том, чтобы помочь клиентам защитить свои сети от нарушения безопасности. Но для того, чтобы стратегия действительно была эффективной, требуется выполнение нескольких важных основных условий:
Правильный веб-токен. Хотя существует целый ряд веб-токенов, ни один из них не может обеспечить ту же надежность, которую предоставляет веб-токен JSON (JWT). JWT считается открытым стандартом (RFC 7519) для передачи конфиденциальной информации между несколькими сторонами. Обмен информацией осуществляется цифровой подписью с использованием алгоритма или сопряжения открытого и закрытого ключей для обеспечения оптимальной безопасности.
Что такое JSON веб-токены?
JSON Web Token (JWT) - это открытый стандарт (RFC 7519), который определяет компактный и автономный способ безопасной передачи информации между сторонами в виде объекта JSON. Эта информация может быть подтверждена благодаря цифровой подписи. JWT может быть подписан с помощью секрета (с помощью алгоритма HMAC) или иным образом, например, по схемам RSA или ECDSA.
В своей компактной форме веб-токены JSON состоят из трех частей, разделенных точками: заголовок, полезная нагрузка, подпись. Поэтому JWT выглядит обычно выглядит следующим образом: «xxxx.yyyy.zzzz».
Заголовок состоит из двух частей: типа токена, которым является JWT, и используемого алгоритма подписи, такого как HMAC SHA256 или RSA.
Публичная информация может быть определена по желанию теми, кто использует JWT. Но они должны быть определены в реестре веб-токенов IANA JSON или определены как URI, который содержит устойчивое к коллизиям пространство имен. Частная - это пользовательская информация, созданная для обмена данными между сторонами, которые согласны их использовать. Получим вторую часть с помощью кодирования Base64Url.
Тоже не понял, что за прикол там происходит.
К плюсам использования JWT можно отнести размер - токены в этом языке кода крошечные и могут быть переданы между двумя пользователями довольно быстро; простоту - токены могут быть сгенерированы практически из любого места, и их не нужно проверять на сервере; контроль - можно указать, к чему пользователь может получить доступ, как долго будет длиться это разрешение и что он может делать во время входа в систему.
Почему стоит использовать токены авторизации?
Многие люди считают, что если текущая стратегия работает хорошо (пусть и с некоторыми ошибками), то нет смысла что-то менять. Но токены авторизации могут принести множество выгод.
Они хороши для администраторов систем, которые часто предоставляют временный доступ, т.е. база пользователей колеблется в зависимости от даты, времени или особого события. Многократное предоставление и отмена доступа создаёт серьёзную нагрузку на людей.
Токены авторизации позволяют обеспечить детальный доступ, т.е. сервер предоставляет доступ на основе определенных свойств документа, а не свойств пользователя. Традиционная система логинов и паролей не допускает такой тонкой настройки деталей.
Токены авторизации могут обеспечить повышенную безопасность. Сервер содержит конфиденциальные документы, которые могут нанести компании или стране серьезный ущерб при выпуске. Простой пароль не может обеспечить достаточную защиту.
Есть и другие преимущества использования этой технологии. Но даже уже перечисленных достаточно, чтобы внедрить её на сервера.
Читайте также: