OAuth2.0 Проверка токена доступа сервером ресурсов

Я пытаюсь реализовать фреймворк авторизации OAuth2.0 в одном веб-проекте на основе Java. Я использую MS Azure как владелец ресурса (R.O) + сервер аутентификации (A.S).

Я также создал несколько настраиваемых областей (например, атрибутов), которые будут включены в токен доступа.

Мой вопрос - when client receives access token from Azure AD and forwards it to the Resource Server, how does resource server(RS) validates this access token ? How can RS decode the token and read the "scope".

RS никогда не был связан с R.O или A.S.

Примечание. Я не хочу использовать OIDC. Я хочу добиться этого только через OAuth2


validation oauth-2.0 token
person Deb    schedule 02.09.2020    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Вот два варианта, которые я вижу на данный момент:

  1. Клиентские отправляющие RS предварительно настроены с помощью client_id и client_secret.
    Client_Id и client_secret генерируются Azure AD, когда подписчик регистрирует приложение. Когда клиент отправляет токен доступа в RS, клиент также включает код, полученный от Azure AD (т. Е. Владелец ресурса, которым является Azure AD). RS теперь может инициировать запрос GET с кодом + client_id. Затем Azure AD может выдать токен доступа обратно в RS. Здесь RS может сопоставить контрольную сумму и проверить, является ли токен доступа таким же (т.е. авторизованным).

  2. Клиент отправляет токен доступа в RS. RS декодирует токен с помощью base64 и проверяет только срок действия и идентификатор клиента. Если истечение срока действия действительно и идентификатор клиента такой же, RS считает, что токен действителен.

1st option seems to be more secured where RS can validate the access token and can also refresh the tokens if required.
person Deb    schedule 04.09.2020

arrow_upward
0
arrow_downward

Я предполагаю, что здесь вы имеете в виду токен JWT. Декодирование токена JWT не представляет большого труда, поскольку токен закодирован только в Base64.

Но проверка токена важна.

Есть два способа проверить токен (токен не поврежден и не закаляется между ними):

  1. Если токен был подписан с использованием симметричного алгоритма (HS256, ...), то в RS должен быть тот же ключ, что и в AS. Думаю, в вашем случае это будет невозможно. Потому что у тебя не будет с собой ключа.
  2. Если токен был подписан с использованием асимметричного алгоритма (RS256, ...). AS будет использовать «закрытый ключ» для подписи токена, а RS будет использовать соответствующий открытый ключ для проверки токена.

Примечание: алгоритм асимметричного ключа - это задача, требующая интенсивного использования ЦП для RS по проверке токена.

person Alok Singh    schedule 04.09.2020
comment
Да, токен ** jwt **. Расшифровка симметричным алгоритмом выглядит немного рискованно. Асимметричный алгоритм выглядит лучше с точки зрения валидации. Не могли бы вы пояснить, как можно получить закрытый ключ из Azure AD. - person Deb; 07.09.2020
comment
Вам необходимо проверить, какой алгоритм используется для подписи токена. Если он асимметричный, вам понадобится открытый ключ от подписывающей стороны. - person Alok Singh; 07.09.2020