Я пытаюсь реализовать структуру авторизации 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

0
Deb 2 Сен 2020 в 10:50

2 ответа

Лучший ответ

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

  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.
0
Deb 4 Сен 2020 в 09:00

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

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

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

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

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

0
Alok Singh 4 Сен 2020 в 10:59