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