OpenID Connect (OIDC)

OpenID Connect to cienka warstwa tożsamości zbudowana na OAuth 2.0. OAuth odpowiada na pytanie co może zrobić ta aplikacja, a OIDC — kim jest użytkownik.

• Standaryzuje sposób uwierzytelniania użytkowników przez klientów i odbierania zweryfikowanych informacji o tożsamości.
• Wprowadza token ID jako podpisane kryptograficznie potwierdzenie uwierzytelnienia.

Przed OIDC programiści niewłaściwie używali tokenów dostępowych OAuth do logowania, co prowadziło do błędów typu confused deputy i podszywania się.

Najważniejszym elementem OIDC jest token ID — podpisany JWT opisujący zdarzenie uwierzytelnienia.

• Zawiera informacje o tym, kto się zalogował i kiedy.
• Jest przeznaczony do przetwarzania przez klienta, a nie przez serwer zasobów.

Nigdy nie należy wysyłać tokenu ID do interfejsu API jako poświadczenia dostępu ani akceptować go bez sprawdzenia podpisu i claims.

Weryfikacja tokenu ID oznacza sprawdzenie określonych claims, a nie tylko podpisu.

• iss wystawcy musi odpowiadać oczekiwanemu IdP.
• aud odbiorców musi zawierać identyfikator client_id.
• exp / iat token nie może być wygasły i musi być wydany niedawno.
• sub to stabilny, unikatowy identyfikator użytkownika.
• nonce musi odpowiadać wartości wysłanej przez klienta.

OIDC ponownie wykorzystuje przepływ Authorization Code, dodając zakres openid i wartość nonce.

• Klient żąda zakresu openid (oraz opcjonalnie profile i email).
• Punkt końcowy tokenów zwraca token ID wraz z tokenem dostępowym.
• Wartość nonce wiąże token ID z pierwotnym żądaniem, zapobiegając ponownemu użyciu.

Dostawcy OIDC publikują swoje klucze podpisujące w punkcie końcowym JWKS, który można znaleźć w dokumencie konfiguracji well-known.

• Należy pobrać klucze z jwks_uri i dopasować nagłówek tokenu kid.
• Należy weryfikować podpis za pomocą wymienionego algorytmu asymetrycznego (RS256, ES256).

Należy odrzucać algorytm none i nigdy nie ufać wartości algorytmu podanej wyłącznie przez token.

Nonce pełni dla tokenów ID taką rolę, jak state dla przekierowania: jest jednorazową wartością wiążącą odpowiedź z żądaniem.

• Klient generuje losową wartość nonce i zapisuje ją w sesji.
• IdP umieszcza ją w tokenie ID.
• Po otrzymaniu tokenu klient sprawdza, czy nonce się zgadza i nie zostało wcześniej użyte.

Blokuje to ponowne użycie tokenu oraz wstrzyknięcie tokenu wystawionego dla innej sesji.

Do pobierania dodatkowych danych profilu wykraczających poza token ID OIDC definiuje punkt końcowy UserInfo.

• Klient wywołuje go za pomocą tokenu dostępowego, a nie tokenu ID.
• Zwraca claims, takie jak imię, adres e-mail i zdjęcie, dotyczące uwierzytelnionego podmiotu.

Aby zapobiec podmianie claims, należy zawsze porównywać zwrócone sub z wartością sub z tokenu ID.

OIDC standaryzuje mechanizm discovery, aby klienci mogli automatycznie konfigurować punkty końcowe i obsługiwane funkcje.

• Dokument /.well-known/openid-configuration zawiera listę punktów końcowych, obsługiwanych zakresów i algorytmów.
• Należy przypiąć wystawcę lub go zweryfikować; nie należy bezkrytycznie korzystać z mechanizmu discovery na hoście kontrolowanym przez atakującego.

Discovery upraszcza integrację, ale wystawca pozostaje kotwicą zaufania, którą należy zweryfikować.

Kończenie sesji w aplikacjach federacyjnych obsługują specyfikacje wylogowania OIDC.

• Wylogowanie front-channel wykorzystuje przekierowania przeglądarki i ramki iframe do wyczyszczenia sesji w każdej stronie ufającej.
• Wylogowanie back-channel wysyła serwerowe tokeny wylogowania; jest bardziej niezawodne, ale wymaga odpowiednich punktów końcowych.

Bez skoordynowanego wylogowania użytkownik może wylogować się z jednej aplikacji, pozostając zalogowanym w innych, co stanowi rzeczywiste zagrożenie dla zarządzania sesjami.

Błędy związane z tożsamością często wynikają z pomijania etapów weryfikacji.

• Akceptowanie tokenów bez sprawdzania aud (token może być przeznaczony dla innego klienta).
• Ignorowanie iss, co umożliwia podszywanie się pod IdP.
• Brak weryfikacji podpisu lub akceptowanie alg: none.
• Mylenie tokenów ID z tokenami dostępowymi.
• Brak sprawdzania nonce, co umożliwia ponowne użycie tokenu.

Jeśli celem jest logowanie, należy użyć OIDC, a nie czystego OAuth.

• Tokeny dostępowe OAuth są nieprzejrzyste dla klienta i nie potwierdzają tożsamości.
• Token dostępowy może być ważny dla innego użytkownika lub aplikacji, co w przypadku użycia go do logowania prowadzi do podszywania się.
• Tokeny ID OIDC są jawnie powiązanymi z odbiorcą potwierdzeniami tożsamości.

To rozróżnienie zapobiega klasycznej luce uwierzytelniania typu confused deputy.

Należy wybrać najważniejszy krok weryfikacji dla strony ufającej, która przetwarza token ID.

Najważniejsze informacje:

• OIDC dodaje warstwę tożsamości do OAuth 2.0; token ID jest podpisanym tokenem JWT potwierdzającym uwierzytelnienie.
• Należy zawsze weryfikować iss, aud, exp, podpis (za pomocą JWKS) i nonce.
• Tokeny ID są przeznaczone dla klientów, a tokeny dostępowe dla interfejsów API — nigdy nie należy zamieniać ich ról.
• Należy używać nonce przeciwko ponownemu użyciu tokenu i state przeciwko CSRF.
• Gdy trzeba uwierzytelniać użytkowników, należy używać OIDC, a nie czystego OAuth.