Protokół OpenID Connect (OIDC) stał się powszechnie przyjętym standardem zarządzania tożsamością. Ale czy naprawdę rozumiesz role i cechy tych tokenów?
Protokół OpenID Connect, znany również jako OIDC, stał się szeroko przyjętym standardem, zapewniającym podstawowe ramy zarządzania tożsamością. Jest to warstwa uwierzytelniania zbudowana na dobrze znanym protokole OAuth 2.0. Podczas gdy OAuth 2.0 jest jedynie do autoryzacji zasobów, OIDC jest protokołem, który standaryzuje i wzmacnia uwierzytelnianie klientów, dzięki nowo wprowadzonej karcie ID.
Czekaj... Mogłeś słyszeć o tokenach dostępu i tokenach odświeżania w erze OAuth, a teraz pojawia się nowe pojęcie w OIDC? Czy naprawdę rozumiesz różnice między tymi tokenami?
Zacznijmy od praktycznego scenariusza.
Wyobraź sobie, że rozwijasz typową aplikację klient-serwer, a one komunikują się ze sobą za pomocą RESTful API. Chcesz, aby większość twoich API była prywatna, pozwalając na dostęp tylko autoryzowanym klientom. Będziesz potrzebował mechanizmu do uwierzytelniania klienta i autoryzacji żądań API do twojego serwera.
Idealnie, twoje RESTful API powinno być bezstanowe, co oznacza, że serwer nie powinien przechowywać żadnych informacji o sesji klienta. Kiedykolwiek przychodzi ważne żądanie, serwer powinien po prostu odpowiedzieć żądanymi danymi. Tu pojawiają się tokeny. Więc jaki rodzaj tokenu powinieneś użyć w takim przypadku?
W OAuth 2.0 i OIDC każde chronione API jest traktowane jako zasób. Token dostępu to dokładnie ten token, który klient przesyła do serwera podczas żądania zasobu API, zazwyczaj przez nagłówek żądania i w formacie JWT.
Po stronie serwera, kiedykolwiek przyjdzie żądanie, serwer musi jedynie sprawdzić, czy przychodzące żądanie zawiera ważny token dostępu. Proces walidacji zazwyczaj obejmuje dekodowanie tokena JWT, weryfikację podpisu i czasu wygaśnięcia, jak również klauzuli scope, aby zapewnić, że klient posiada niezbędne uprawnienia.
Jednakże, możesz się zastanawiać: Jeśli moja aplikacja klientowska może mieć ważny token dostępu po pomyślnym logowaniu i używać tokenu dostępu do żądania API serwera, czy to nie wystarczy? Dlaczego potrzebuję innych tokenów?
Rzeczywiście, to ważne pytanie, wyjaśnijmy to krok po kroku.
Chociaż technicznie tokeny dostępu spełniają minimalne wymagania do działania systemu, ze względu na kwestie bezpieczeństwa ich ważność jest zazwyczaj bardzo krótka (zwykle godzina). Więc wyobraź sobie, że mamy tylko tokeny dostępu, użytkownicy końcowi będą musieli uwierzytelniać się ponownie za każdym razem, gdy token dostępu wygaśnie. Dla nowoczesnych jednostronicowych aplikacji internetowych (SPA) i zwłaszcza aplikacji mobilnych, częste wylogowywanie to raczej bolesne doświadczenie użytkownika, chociaż próbujemy jedynie chronić ich bezpieczeństwo.
Dlatego potrzebujemy równowagi między bezpieczeństwem tokenów a wygodą użytkownika. Dlatego wprowadzone są tokeny odświeżania.
Tokeny dostępu są używane do dostępu do zasobów API, więc ich krótkotrwała natura pomaga w zmniejszeniu ryzyka wycieku lub złamania. Z drugiej strony, ponieważ tokeny odświeżania są używane jedynie do wymiany na nowe tokeny dostępu, nie są używane tak często jak tokeny dostępu i dlatego ryzyko ich ujawnienia jest zredukowane. Dlatego posiadanie dłuższego okresu ważności jest uważane za akceptowalne dla tokenów odświeżania.
Ponieważ token odświeżania jest również przechowywany po stronie klienta, zapewnienie jego niekompromitacji jest wyzwaniem, zwłaszcza dla klientów publicznych, takich jak jednostronicowe aplikacje webowe (SPA) i aplikacje mobilne.
W Logto tokeny odświeżania mają domyślnie włączony automatyczny mechanizm rotacji, co oznacza, że serwer autoryzacji wyda nowy token odświeżania, gdy spełni określone kryteria:
Chociaż nadal masz możliwość wyłączenia rotacji tokenu odświeżania na stronie szczegółów aplikacji w konsoli administracyjnej, zdecydowanie zaleca się zachowanie tego zabezpieczenia.
Token ID jest unikalną cechą OIDC, która dostarcza informacji o tożsamości uwierzytelnionego użytkownika.
Podczas gdy tokeny dostępu są używane do dostępu do chronionych zasobów, a tokeny odświeżania są używane do uzyskiwania nowych tokenów dostępu, tokeny ID są zazwyczaj używane do przechowywania informacji o użytkowniku po stronie klienta, zmniejszając potrzebę składania dodatkowych żądań do serwera autoryzacji o dane użytkownika. W większości przypadków można nawet bezpiecznie powiedzieć, że posiadanie tokenu ID jest równoznaczne z tym, że użytkownik jest uwierzytelniony.
W protokole OIDC tokeny odświeżania, tokeny dostępu i tokeny ID współdziałają, aby zapewnić bezpieczne i płynne uwierzytelnianie użytkowników.
Zrozumienie roli i znaczenia tych tokenów jest kluczowe dla deweloperów wdrażających uwierzytelnianie OIDC w swoich aplikacjach.