Uprawnienia OpenID Connect i tokeny ID

OpenID Connect (OIDC) dodaje warstwę tożsamości do OAuth 2.0. OAuth 2.0 obsługuje autoryzację (do czego ta aplikacja ma dostęp?), natomiast OIDC odpowiada na pytanie dotyczące tożsamości (kim jest użytkownik?). OIDC wdraża się przez dodanie zakresu "openid" do żądania OAuth 2.0, co powoduje, że serwer autoryzacji zwraca token ID wraz z tokenem dostępu.

Token ID OIDC jest tokenem JSON Web Token (JWT) zawierającym claims dotyczące uwierzytelnionego użytkownika. JWT jest podpisywany przez serwer autoryzacji przy użyciu jego klucza prywatnego (zwykle RS256 lub ES256), a strona ufająca (aplikacja kliencka) weryfikuje podpis za pomocą opublikowanych kluczy publicznych serwera autoryzacji (punkt końcowy JWKS).

Wymagane i często używane claims tokenu ID: "sub" (subject — unikalny identyfikator użytkownika), "iss" (issuer — adres URL serwera autoryzacji), "aud" (audience — identyfikator klienta), "exp" (znacznik czasu wygaśnięcia w formacie Unix), "iat" (znacznik czasu wystawienia w formacie Unix). Opcjonalne: "auth_time" (czas uwierzytelnienia), "nonce" (ochrona przed ponownym użyciem), "at_hash" (skrót tokenu dostępu), "acr" (klasa kontekstu uwierzytelniania), "amr" (użyte metody uwierzytelniania).

Punkt końcowy UserInfo zwraca dodatkowe claims dotyczące uwierzytelnionego użytkownika, gdy zostanie wywołany z użyciem prawidłowego tokenu dostępu. Klienci żądają określonych zestawów claims za pomocą zakresów: "profile" (nazwa, zdjęcie, ustawienia regionalne), "email" (adres e-mail, informacja o weryfikacji adresu), "address" (sformatowany adres), "phone" (numer telefonu, informacja o weryfikacji numeru). Odpowiedź UserInfo jest obiektem JSON lub JWT.

Weryfikacja tokenu ID rozpoczyna się od sprawdzenia podpisu. Klient pobiera JWKS (JSON Web Key Set) serwera autoryzacji z dobrze znanego punktu końcowego, znajduje klucz odpowiadający parametrowi "kid" (identyfikator klucza) w nagłówku JWT i weryfikuje podpis JWT. Dowodzi to, że token został wystawiony przez prawidłowy serwer autoryzacji i nie został zmodyfikowany.

Po weryfikacji podpisu klient musi sprawdzić: wartość "iss" musi dokładnie odpowiadać oczekiwanemu adresowi URL serwera autoryzacji (włącznie ze schematem i ścieżką). Wartość "aud" musi zawierać client_id klienta. Wartość "exp" musi wskazywać czas w przyszłości (wygasłe tokeny należy odrzucać). Wartość "iat" powinna wskazywać stosunkowo niedawny czas. Wszystkie cztery kontrole są wymagane przez specyfikację OIDC.

Claim nonce zapobiega atakom polegającym na ponownym użyciu tokenu ID. Klient generuje losową wartość nonce i dołącza ją do żądania autoryzacji. Serwer autoryzacji umieszcza nonce w tokenie ID. Klient sprawdza, czy nonce w tokenie ID odpowiada wartości wysłanej przez klienta. Zapobiega to napastnikowi, który przechwycił token ID, ponownemu użyciu go w celu uwierzytelnienia innej sesji.

Gdy OIDC używa przepływu niejawnego (response_type=id_token), token ID jest zwracany bezpośrednio we fragmencie adresu URL. Klient musi zweryfikować at_hash (skrót tokenu dostępu), aby powiązać token dostępu z tokenem ID. Bez weryfikacji at_hash możliwe są ataki polegające na podmianie tokenu dostępu. Jest to kolejny powód wycofania przepływu niejawnego.

OIDC definiuje standardowe mapowania zakresów na claims. Zakres "openid" jest wymagany i zwraca claim "sub". Zakres "profile" zwraca name, given_name, family_name, nickname, picture, website, locale, zoneinfo, updated_at. Zakres "email" zwraca email i email_verified. Żądanie niepotrzebnych zakresów narusza zasadę minimalnego ujawniania informacji i może prowadzić do ujawnienia poufnych danych użytkownika.

Podczas implementowania logowania OIDC z użyciem wielu dostawców (np. "Sign in with Google" i "Sign in with GitHub") możliwe są ataki polegające na wstrzykiwaniu claims. Jeśli napastnik utworzy konto u dostawcy B z adresem e-mail ofiary, która korzysta z dostawcy A, może uzyskać dostęp, jeśli aplikacja dopasowuje konta wyłącznie na podstawie claim adresu e-mail. Konta należy zawsze dopasowywać na podstawie pary (iss, sub), a nie samego adresu e-mail.

Przepływ hybrydowy OIDC (response_type=code id_token) zwraca zarówno kod autoryzacyjny, jak i token ID z punktu końcowego autoryzacji. Token ID umożliwia natychmiastową weryfikację tożsamości, a kod jest wymieniany na tokeny za pośrednictwem kanału zaplecza. Stosuje się go, gdy klient musi natychmiast wyświetlić informacje o użytkowniku przed zakończeniem wymiany tokenu za pośrednictwem kanału zaplecza.

Jaką kombinację claims strona ufająca musi zweryfikować w tokenie ID OIDC?

OIDC dodaje podpisany token ID JWT do przepływów OAuth 2.0. Należy zweryfikować podpis (JWKS), iss (dokładna zgodność), aud (client_id), exp (token nie wygasł) oraz nonce (jeśli został wysłany). Punkt końcowy UserInfo udostępnia dodatkowe claims za pomocą zakresów. Aby zapobiec wstrzykiwaniu claims, konta należy dopasowywać na podstawie pary (iss, sub), nigdy wyłącznie na podstawie adresu e-mail. Przepływ niejawny jest wycofany; w OIDC należy używać przepływu z kodem autoryzacyjnym i PKCE.