Связь OAuth v2 между аутентификацией и сервером ресурсов


82

У меня проблемы с пониманием того, как работает OAUTH-v2.

Спецификация OAuth версии 2 гласит:

  1. Доступ к защищенным ресурсам

    Клиент получает доступ к защищенным ресурсам, представляя
    маркер доступа серверу ресурсов. Сервер ресурсов ДОЛЖЕН проверить
    токен доступа и убедиться, что срок его действия не истек и что его область действия охватывает
    запрошенный ресурс. Методы , используемые сервером ресурсов для
    проверки маркера доступа (а также любые ответы ошибок) выходит за рамки данной спецификации , но , как правило включают взаимодействие или координацию между сервером ресурсов и авторизации
    сервера
    .

Как это взаимодействие между сервером ресурсов и сервером авторизации работает на практике?

  • Как сервер ресурсов определяет, что полученный токен доступа действителен?
  • Как сервер ресурсов извлекает разрешенную область из токена, чтобы узнать, следует ли предоставить доступ к определенному ресурсу? Закодирован ли Scope в токене доступа, или сервер ресурсов сначала должен связаться с сервером авторизации?
  • Как устанавливается доверие между сервером ресурсов и сервером авторизации?

Атрибуты токена доступа и методы, используемые для доступа к защищенным ресурсам, выходят за рамки данной спецификации и определяются сопутствующими спецификациями.

Может кто-нибудь привести примеры атрибутов токена?


1
Это действительно вопрос, который я ищу несколько дней назад
Уттам

Ответы:


79

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

Например, есть ли у вас один сервер, управляющий аутентификацией и доступом, и набор дискретных служб, каждая со своими собственными серверами, обслуживающими вызовы API? Или у вас есть только один ящик с одним веб-сервером, который обрабатывает как аутентификацию / авторизацию, так и вызовы API?

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

При работе с распределенной средой все становится немного сложнее, но ненамного. Вы по-прежнему выпускаете токены на сервере авторизации, но серверу ресурсов нужен способ их проверки. Он может сделать это, сделав внутренний API доступным для сервера ресурсов, чтобы попросить сервер авторизации «разрешить» токен (что может быть быстрым в локальной среде), или оба могут установить пару открытого / закрытого ключей или симметричный секрет и используйте это, чтобы зашифровать все, что требуется серверу ресурсов, в токен.

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


Верно ли, что если объект, выпускающий и проверяющий токены, не имеет статического белого / общедоступного IP-адреса, тогда обратные вызовы поставщика услуг для владельца / клиента не могут быть выполнены через HTTP (s), что требует более сложных реализаций?
Денис С.

Обратные вызовы выполняются не поставщиком услуг, а браузером пользователя. Не уверен, что именно вы спрашиваете.
Эран Хаммер

Что произойдет, если вы добавите некоторый API, который использует сервер ресурсов (принадлежащий вам API). Следует ли затем использовать аутентификацию oath2 (client_credentials), устанавливающую безопасную межмашинную связь с сервером ресурсов? В этом случае означает ли это, что все API-интерфейсы должны использовать одну и ту же пару ключей с сервером аутентификации?
Dionisis K

4

Одним из примеров API сервера авторизации является тот, который представлен на веб-сайте Google Developers .
Он не определяет формат токена доступа, но ответ кажется универсально полезным.


OIDC и id_tokens чем-то отличаются от токенов доступа obaque.
мачете
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.