Как сервер ресурсов должен проверять токен носителя oauth, выданный сервером авторизации?

Question

Предположим, у меня есть сервер авторизации (AS), который должен создавать access_token, и что у меня есть другой сервер ресурсов (RS), который обслуживает мои защищенные ресурсы.

Мне интересно как RS должен проверять access_token, созданный AS?

Меня беспокоит то, что AS должен иметь свой секретный способ подписания access_token, который не предназначен для совместного использования или получения информации кем-либо еще, что в В этом случае RS не должен иметь никакого представления о том, как AS сгенерировал этот access_token.

В этом случае, как RS должен проверить полученный токен и убедиться, что токен поступает из распознанной AS? Вместо этого, разве AS не должна проверять полученный токен на RS? Но если это так, разве он не столкнется с каким-либо узким местом производительности, поскольку каждый вызов API в RS потребует дополнительного перехода к AS для проверки токена?

Answer 1

Как вы говорите Isaa c, некоторые люди (включая меня) предпочитают извлекать проверку токена из API и просить сервер авторизации выполнить эту работу. Я думаю, что это самый чистый вариант, так как:

• Он выводит код безопасности из всех ваших API
• Ключ или алгоритм подписи токена можно изменить без воздействия на API

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

Несколько моих связанных ресурсов:

• Блог авторизации API Сообщение
• Код интроспекции

Техника, которую описывает Tore, также совершенно верна и является обязательным требованием, если сервер авторизации не поддерживает интроспекцию.

Answer 2

Обычно токены, выпущенные AS, подписываются с использованием закрытого ключа. AS также публикует ключ публикации c, который может загрузить любой желающий. Например, Google публикует свой publi c siging key здесь .

Позже, когда RS получает токен доступа, он загружает publi c ключ из AS и проверяет подпись. токена. Если совпадение принято. Помимо проверки подписи, он также проверяет другие утверждения внутри токена, такие как аудиторское утверждение (аудитория), действительно ли этот токен предназначен для потребления RS.

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