Ten post na blogu ma na celu rzucić światło na związek między wskaźnikami zasobów OIDC a ich rolą w uzyskiwaniu tokenów dostępu.
W poprzedniej sesji, zapewniliśmy wprowadzenie do protokołu OpenID Connect (OIDC), tokenów odświeżających, tokenów dostępu i tokenów ID, niezbędnych elementów do budowania solidnej autentykacji w Twojej aplikacji. Jednak pytania nadal się pojawiają w naszej społeczności, z jednym powtarzającym się zapytaniem: "Dlaczego mój token dostępu nie jest JWT?”
Dla tych, którzy są nowi w tych koncepcjach, a nawet dla tych, którzy potrzebują przypomnienia, ten post na blogu ma na celu rzucić światło na związek między wskaźnikami zasobów OIDC a ich rolą w uzyskiwaniu tokenów dostępu.
Jeśli jesteś zaznajomiony z protokołem OAuth 2.0, termin “zasób” powinien Ci się kojarzyć. Ponieważ OIDC jest zbudowane na bazie OAuth 2.0, dziedziczy ten sam koncept.
"Zasób" lub "chroniony zasób" to reprezentacja jednostki, do której klient aplikacji chce uzyskać dostęp w imieniu uwierzytelnionego użytkownika. Mogą to być informacje o użytkowniku, serwerowe API czy inne dane autoryzowane przez Twój serwer.
Zgodnie z protokołem, zasób jest parametrem w żądaniach do serwera autoryzacji. Jest to wartość reprezentowana jako absolutne URI, takie jak https://my-company.com/api. Działa jako identyfikator zasobu, potencjalnie odpowiadając lokalizacji dostępnej w sieci lub nawet unikalnemu, ale fikcyjnemu URI.
W Logto możesz utworzyć „zasób API” poprzez stronę „Konsola administracyjna → Zasoby API”. Możesz odnieść się do tej dokumentacji po więcej szczegółów.
Format tokena dostępu JWT jest wydawany tylko wtedy, gdy parametr "zasób" jest określony podczas żądania tokena dostępu, a zawartość to zestaw roszczeń, które można zdeszyfrować i sprawdzić, na przykład, aby zapewnić integralność tokena i uprawnienia użytkownika.
Ten "zasób" staje się jednym z roszczeń tokenu aud w JWT, wskazując przewidywaną publiczność dla tokena. Zobacz RFC-7519.
Więc, związek staje się jasny:
aud.aud oraz inne roszczenia związane z uprawnieniami, aby zabezpieczyć żądanie API.🤔 Ale co jeśli klient nie określi zasobu podczas żądania tokena dostępu?
W przypadku Logto, jeśli wskaźnik zasobu nie jest określony podczas żądania tokena dostępu, serwer autoryzacji zakłada, że jest to dla punktu końcowego OIDC /userinfo, a zatem zostanie wydany opaque token dostępu, który później może być użyty przez klienta do żądania profilu użytkownika, takiego jak ID użytkownika, nazwa, adres e-mail, itp., z punktu końcowego userinfo OIDC.
W dowolnym SDK Logto, można uzyskać taki token, jeśli wywołasz getAccessToken() lub bezpośrednio żądasz punktu końcowego tokenu OIDC bez określania parametru resource.
Należy zauważyć, że ten opaque token dostępu nie jest odpowiedni do żądań dotyczących własnego zasobu API, ponieważ nie ma możliwości jego weryfikacji bez żądania serwera OIDC.
Zasoby OIDC definiują konkretne dane lub usługi, do których klient aplikacji chce uzyskać dostęp w imieniu użytkownika, przy tokenach dostępu JWT służących jako bezpieczny środek dostępu. Roszczenie "aud" w tokenach dostępu JWT pasuje do wskaźnika zasobu, pomagając serwerom w weryfikacji uprawnień przy żądaniach klienta.
W Logto, opaque token dostępu służy wyłącznie do pobierania informacji o profilu użytkownika z punktu końcowego userinfo OIDC, podczas gdy klienci mogą żądać wielu tokenów dostępu, każdy dedykowany konkretnemu zasobowi.
Mamy nadzieję, że ten post na blogu rozwieje wszelkie wątpliwości i połączy kropki dla Ciebie. Nie krępuj się podzielić z nami swoimi przemyśleniami.