Ten artykuł bada introspekcję tokenu OAuth 2.0, metodę, która pozwala chronionemu zasobowi na zapytanie serwera autoryzacji o metadane tokenu, określając, czy token dostępu lub odświeżający jest ważny.
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ą:
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:
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.
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:
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.
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.