Кто выпустил токен на предъявителя

Question

Мой сервер получает токен-носитель в заголовке примерно так: Authorization: Bearer <token>.Теперь мне нужно проверить этот токен, и чтобы это произошло, мне нужно, кто выдаст токен.Например, токен Google потребовал бы, чтобы я проверил его с помощью API Google, а токен, выданный Facebook, потребовал бы, чтобы я проверил его с помощью API Facebook.

Так как я могу узнать, откуда произошел токен?Возможно, мне нужно другое поле в заголовке, которое указывает его происхождение?

Answer 1

Поскольку вы используете несколько поставщиков авторизации, я полагаю, что вы не используете другие области, кроме profile (для получения идентификатора пользователя).Поэтому я думаю, что вы могли бы использовать свой собственный сервер OAuth2, который поддерживает аутентификацию с использованием внешних провайдеров (Google, Facebook).Тогда ваше приложение будет иметь дело только с токенами доступа, выпущенными вашим сервером OAuth2, которые также будут хранить информацию о личности пользователя.Это решение имеет дополнительное преимущество, заключающееся в том, что вы можете поддерживать пользователей без учетной записи социальной сети - они создадут новую учетную запись на вашем сервере OAuth2.

Другое решение, вероятно, менее изящно, но проще в реализации.Создайте правило, что перед использованием токена доступа клиенты должны зарегистрировать токен на какой-либо новой конечной точке с информацией об эмитенте токена (Google, Facebook ...).Затем вы можете сохранить информацию о том, кто выдал какой токен.На этом этапе, после проверки токена доступа, вы также можете рассмотреть вопрос о замене токена для файла cookie сеанса, который позже будет использоваться для доступа к вашему API вместо токена доступа.Это решение с отслеживанием состояния, что затрудняет его масштабирование, но использование файлов cookie, вероятно, облегчит реализацию клиентов (не нужно обновлять токены).

Как вы уже писали, вам также может потребоваться дополнительная информация о том, кто выдалмаркер.Вы можете использовать собственный заголовок HTTP или префикс токена для него.Его легко реализовать, и он не привнесет состояние в ваш бэкэнд.

Возможно, есть еще несколько решений.Вам решать, какой из них будет соответствовать вашим потребностям.

Answer 2

Если вы подразумеваете, что Authorization: Bearer <token> означает использование токена на предъявителя, определяемое как RFC6750 , то есть несколько вариантов для рассмотрения.

Если каким-либо образом токен (токен отправляется в заголовке)) является веб-токеном JSON (JWT), тогда ваш API может проверить параметр эмитента в JWT, чтобы идентифицировать эмитента.Чтобы использовать этот подход, клиенту, отправляющему запрос, необходимо получить токены доступа JWT.Проконсультируйтесь с различными поставщиками об этой возможности.

Если первая опция не удалась, вам придется использовать пользовательский заголовок для передачи сведений об эмитенте.Токены доступа по определению (кроме случаев, когда используется JWT) непрозрачны, поэтому у вашего API нет возможности определить эмитента, посмотрев на него.Таким образом, ваш клиент должен будет сообщить детали эмитента.

Третий вариант - зарегистрировать клиента, прежде чем он сможет использовать ваш API.После регистрации вы можете выдать им идентификатор, который вы можете сопоставить с эмитентом токена доступа.Когда клиент делает запрос, вы можете попросить его передать информацию о клиенте, например, через заголовок.Таким образом, вы ограничиваете возможности использования API для всех, кто может получить токен доступа.