Introspekcja tokenu OAuth 2.0

Introspekcja tokenu OAuth 2.0 definiuje metodę, która pozwala autoryzowanemu chronionemu zasobowi na zapytanie serwera autoryzacji w celu określenia metadanych związanych z danym tokenem (czy to tokenem dostępu, czy odświeżającym), dostarczonym przez klienta OAuth. Na podstawie metadanych konkretnego tokenu, pozwala właścicielowi zasobu na dostęp do chronionego zasobu.

Te metadane obejmują:

• Czy token jest obecnie aktywny (lub czy wygasł lub został odwołany)
• Uprawnienia, które przyznaje token dostępu (zazwyczaj przekazywane przez zakresy OAuth 2.0)
• Kontekst autoryzacji, w którym token został przyznany (w tym kto autoryzował token i do którego klienta został wydany)

Introspekcja tokenu umożliwia chronionemu zasobowi zapytanie tych informacji, niezależnie od tego, czy są one zawarte w samym tokenie.

Istnieją dwa typy tokenów dostępu, w zależności od tego, jak są kodowane:

• Oparte na identyfikatorze: Token reprezentuje losowy, trudny do odgadnięcia identyfikator związany z autoryzacją w bazie danych serwera autoryzacji.
• Samodzielne: Autoryzacja jest zakodowana w samym tokenie i jest zabezpieczona za pomocą kryptografii, aby zapobiec manipulacjom. JSON Web Token (JWT) jest powszechnym standardem dla tej metody.

Dla samodzielnych tokenów metadane związane z autoryzacją mogą być bezpośrednio analizowane z tokenu dostępu. Jednak w przypadku tokenów opartych na identyfikatorze funkcja introspekcji tokenu serwera autoryzacji musi być użyta do walidacji/pobrania metadanych.

Żądanie introspekcji tokenu#

Użycie tokenów dostępu opartych na identyfikatorze wymaga weryfikacji za pomocą serwera autoryzacji poprzez żądanie sieciowe. Istnieje standardowy protokół dla tego, zwany Introspekcja Tokenów OAuth 2.0 (RFC 7662).

Chroniony zasób wyśle token do punktu końcowego introspekcji serwera autoryzacji, a w zamian otrzyma obiekt JSON zawierający parametry tokenu.

Należy zauważyć, że żądania introspekcji nie mogą być inicjowane dowolnie; muszą spełniać jedno z następujących warunków:

• Uwierzytelnianie za pomocą poświadczeń (które muszą być wcześniej zarejestrowane na serwerze autoryzacji) lub
• Autoryzacja za pomocą tokenu dostępu.

W wyniku tego konkretnego interakcji chroniony zasób staje się klientem OAuth, a serwer autoryzacji staje się chronionym zasobem.

Poniżej znajduje się przykład żądania introspekcji, gdzie chroniony zasób uwierzytelnia się za pomocą identyfikatora klienta i sekretu klienta, które zostały uzyskane po rejestracji jako klient OAuth w serwerze autoryzacji.

Poniżej znajduje się przykład żądania introspekcji, które bezpośrednio używa tokenu dostępu. Token dostępu może być uzyskany bezpośrednio z punktu końcowego /token, używając poświadczeń zarejestrowanej aplikacji "machine-to-machine" i grant type client_credentials.

Odpowiedź introspekcji tokenu#

Najważniejszym parametrem jest active, który jest wartością boolean. Jeśli true, wskazuje, że token jest ważny, a obiekt JSON będzie zawierał inne szczegóły tokenu, takie jak wartości zakresu. Jeśli false, token jest nieważny lub wygasł, a chroniony zasób musi zwrócić odpowiedź 401 Unauthorized z kodem błędu invalid_token.

Oto przykład odpowiedzi dla ważnego tokenu:

Poza active, który jest wymagany, wszystkie inne parametry są opcjonalne.

Chroniony zasób może użyć tych dodatkowych pól, aby określić uprawnienia dostępu, podobnie jak analizowałby i weryfikował token dostępu JWT.