Как различаются токены доступа между поставщиками ресурсов в OpenID Connect?

Я работаю над созданием поставщика OpenID Connect (OIDC) на основе django-oidc-provider. Я читал спецификацию OpenID Connect Spec и не могу понять, насколько токены доступа уникальны для определенного приложения.

Рассмотрим следующий пример с пользователем Бобом:

Боб хочет войти в приложение A, поэтому он переходит к его интерфейсу и перенаправляется к поставщику OIDC. После аутентификации он перенаправляется (неявный поток) обратно в Приложение A с токеном ID и токеном доступа. Затем он делает запрос по адресу «/ image / 1» к API A со своим токеном доступа. API использует токен доступа, чтобы связаться с поставщиком OIDC и подтвердить личность пользователя как Боба. Затем API возвращает данные в «/ image / 1» для пользователя Боба, если такая информация существует. Боб продолжает отправлять свой токен доступа в API A для любых последующих запросов.

Затем Боб решает, что он хочет получить доступ к API приложения B. Он отправляет B API тот же токен доступа, который он использовал с API A. API B обращается к поставщику OIDC с токеном и подтверждает личность пользователя как Боба. Затем API B возвращает запрошенную информацию для Боба.

Что мешает этому случиться? Я вижу как минимум два возможных решения этого:

  1. При обращении к конечной точке проверки токенов Google "aud" возвращается параметр. API приложения B должен будет проверить этот параметр, чтобы решить, что токен недействителен для его собственного API?
  2. Дополнительная область должна быть добавлена ​​при запросе токена, специфичного для поставщика ресурсов, например app-A-api. Затем, когда API проверяет токен, API гарантирует, что токен содержит необходимую область.

Какие из этих или других методов соответствуют спецификации OIDC? Если следует использовать одно из вышеперечисленных, правильно ли я предполагаю, что мне следует добавить новую конечную точку / tokeninfo, которая возвращает область видимости или aud, а не добавлять эту информацию к информации, возвращаемой конечной точкой / userinfo?

Любой вклад приветствуется. Я думаю, что большая часть моей путаницы возникает из-за того, что я не вижу параметра «scope», используемого для делегирования доступа поставщику ресурсов в каких-либо примерах OIDC.


person Panda    schedule 27.04.2017    source источник


Ответы (1)


Я думаю, вам не хватает того, что приложение A и его API - это два отдельных приложения. Таким образом, токены выдаются для приложения A. Если app-A-api использует токен доступа только для аутентификации пользователя, лучше использовать токен ID - его можно проверить без доступа к серверу OAuth2. В этом сценарии app-A-api самостоятельно управляет своими разрешениями пользователей.

Если app-A-api нужен токен для получения списка областей (разрешений) своего клиента, используйте токен доступа. Но в этом сценарии app-A-api (и app-B-api) просто принимают токен доступа - они не являются целевой аудиторией (атрибут aud) токена. Приложение A - это аудитория токенов.

API просто проверяют, содержит ли токен доступа релевантные для них области. Они доверяют эмитенту токенов, и пользователи сами решают, доверяют ли они приложению A выполнять действия от их имени.

Например, если приложение JavaScript C (приложение-C) использует для своих действий только Google Диск и Google Plus, то app-C запросит у пользователя токен доступа с областями, принадлежащими Google Диску и Google Plus. Это будет всего лишь один токен, и оба API Google его примут.

Что касается конечной точки tokeninfo, у нее есть собственный RFC под названием OAuth 2.0 Token Introspection, так что вы можете Проверь это.

person Ján Halaša    schedule 28.04.2017
comment
Интересный ответ. Хочу указать, что аудитория токена может быть ограничена сервером авторизации или конфигурацией клиента (1 клиент на 1 RS). Кроме того, в этом проекте IETF вы найдете способ позволить клиенту указать, какой RS относится к запросу авторизации. - person Spomky-Labs; 28.04.2017
comment
Спасибо Флорану за информацию. Мне не было известно о проекте индикаторов ресурсов. - person Ján Halaša; 28.04.2017
comment
Хотя это полезно знать, мне не нужен специальный токен на основе запрошенного ресурса (как описано в этом проект IETF). Затем из двух моих решений, если я правильно понимаю, лучше, чтобы API проверял область, которая была дополнительно запрошена при авторизации, а не проверять параметр aud, так как это упростит отзыв токена и позволит токену быть используется для нескольких API? - person Panda; 28.04.2017