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, когато абонатът регистрира APP. Когато клиентът изпрати токен за достъп до 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.

Но валидирането на токена е важно.

Има 2 начина за валидиране на токена (токенът е непокътнат и не е темпериран между тях):

  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