Token ID a access token: kluczowa różnica w OpenID Connect

By Mirko Peters · 2026-10-28

Poznaj kluczowe różnice między tokenami ID a access tokenami w OpenID Connect i dowiedz się, dlaczego ich pomylenie prowadzi do poważnych luk w zabezpieczeniach.

Automatically translated with AI from the original post. Read the English original

Zrozumienie różnicy między tokenem ID a access tokenem ma kluczowe znaczenie dla deweloperów i administratorów IT pracujących z nowoczesnym uwierzytelnianiem. OAuth 2.0 odpowiada za uprawnienia, natomiast OpenID Connect wprowadza token ID, który potwierdza tożsamość użytkownika. Pomylenie tych dwóch różnych tokenów prowadzi do krytycznych luk w zabezpieczeniach aplikacji chmurowych.

Najważniejsze wnioski

• Tokeny ID potwierdzają tożsamość użytkownika, natomiast access tokeny przyznają autoryzację i uprawnienia.
• Pomylenie tych dwóch tokenów to główny błąd w zabezpieczaniu aplikacji tworzonych we własnym zakresie.
• OpenID Connect dodaje potwierdzanie tożsamości na bazie struktury OAuth 2.0.
• Access tokeny można unieważnić, co stanowi bezpieczniejsze podejście niż przechowywanie haseł.
• Aplikacje muszą kryptograficznie weryfikować przychodzące tokeny ID, zamiast ślepo im ufać.

Główny dylemat: tożsamość kontra autoryzacja

W rozwoju nowoczesnych aplikacji webowych deweloperzy często mają problem ze zrozumieniem, jak użytkownicy się logują i jak później korzystają z danych. Duża część tego zamieszania wynika z nakładających się terminów z obszaru tożsamości. Gdy aplikacje zaczęły szybko rozprzestrzeniać się w sieci, poleganie wyłącznie na prostych kombinacjach nazwy użytkownika i hasła stało się poważnym wąskim gardłem w kwestii bezpieczeństwa. Użytkownicy byli zmęczeni zarządzaniem dziesiątkami unikalnych poświadczeń, co prowadziło do słabego, powtarzanego na wielu platformach hasła.

Aby rozwiązać część tego problemu, pojawiło się OAuth 2.0. Nigdy jednak nie zostało zaprojektowane do odpowiadania na pytanie, kim jest dana osoba. Jego celem jest wydawanie „przepustek” – zwanych access tokenami – które pozwalają aplikacji w imieniu użytkownika docierać do określonych punktów końcowych z danymi. Access token określa, co aplikacja może robić, ale w zupełności milczy na temat tożsamości osoby, która go posiada. Ta zasadnicza luka sprawiła, że firmy próbujące tworzyć rozwiązania单一 logowania (SSO) musiały dodawać własne, niestandardowe weryfikacje tożsamości do OAuth, co prowadziło do rozproszonych implementacji, które rzadko były ze sobą zgodne.

OpenID Connect wypełnił tę dokładnie lukę, wprowadzając ustandaryzowaną warstwę przeznaczoną specjalnie do uwierzytelniania. Dzięki zastosowaniu drugiego tokena obok tradycyjnego access tokena OpenID Connect czytelnie oddziela kwestię tożsamości od kwestii uprawnień. Utrzymanie tych dwóch pojęć osobno to najważniejsza zmiana sposobu myślenia dla każdego, kto dziś buduje lub audytuje aplikacje chmurowe.

Anatomia tokena ID: co się w nim znajduje

Gdy użytkownik kliknie przycisk „Zaloguj się przez Microsoft”, dostawca tożsamości weryfikuje dane logowania, obsługuje wymagania uwierzytelniania wieloskładnikowego i ostatecznie odsyła użytkownika do aplikacji, dołączając token ID. Token ten jest zapisany jako JSON Web Token, w skrócie JWT, wymawiany jako „dżot”. Na pierwszy rzut oka JWT wygląda jak nieprzeniknione ciągi znaków oddzielone kropkami. Jego wewnętrzna struktura jest jednak zaskakująco prosta po zdekodowaniu.

Token ID zawiera kilka standardowych oświadczeń, z których każde ma ściśle określony cel:

• Wystawca (iss): Identyfikuje konkretnego dostawcę tożsamości (np. Microsoft Entra ID), który wygenerował i podpisał token.
• Subject (sub): Służy jako unikalny, niezmienny identyfikator użytkownika. Co istotne, jest zaprojektowany tak, aby się nie zmieniał, nawet jeśli użytkownik zaktualizuje swoją nazwę wyświetlaną lub adres e-mail.
• Audience (aud): Określa, dla której dokładnie aplikacji wystawiono token, dzięki czemu token przeznaczony dla jednej aplikacji nie może zostać złośliwie przechwycony i ponownie użyty przez inną.
• Znaczniki czasu: Pokazują, kiedy token został wystawiony, kiedy wygasa oraz dokładny moment uwierzytelnienia użytkownika.
• Nonce: Działa jak bezpieczny numer kwitu, który wiąże wynikowy token z konkretną sesją logowania, która zainicjowała żądanie, skutecznie blokując ataki typu replay.

Co istotne, cały pakiet jest podpisany kluczem prywatnym dostawcy. Aplikacja odbierająca weryfikuje ten podpis za pomocą pasującego klucza publicznego opublikowanego przez dostawcę. Bez tej weryfikacji kryptograficznej token ID jest niczym więcej niż niezweryfikowaną notatką przekazywaną między stronami.

Niebezpieczeństwo traktowania tożsamości jako dostępu

Jednym z najbardziej niebezpiecznych antywzorców w tworzeniu aplikacji jest traktowanie tokenu ID jako klucza uprawnień. Ponieważ token ID potwierdza, że użytkownik to John Doe z określonej organizacji, niedoświadczeni programiści czasem popełniają błąd, wykorzystując to potwierdzenie do przyznawania uprawnień administracyjnych lub nieograniczonego dostępu do bazy danych. To zasadniczo źle rozumie architekturę.

Token ID jedynie informuje, kto stoi przy drzwiach wejściowych; nie rozstrzyga, czy ta osoba może wejść do każdego pomieszczenia lub kliknąć konkretny przycisk administracyjny. Logikę autoryzacji musi obsłużyć aplikacja osobno, z użyciem kontroli dostępu opartej na rolach lub podobnych mechanizmów, traktując zweryfikowaną tożsamość jako punkt wyjścia, a nie ostateczną decyzję o autoryzacji.

Ponadto aplikacje często popełniają błąd, akceptując przychodzące tokeny ID bez przeprowadzania właściwej walidacji. Ślepe zaufanie tokenowi tylko dlatego, że biblioteka przetworzyła go w tle, naraża systemy na sfałszowane dane. Weryfikacja podpisu, sprawdzenie znaczników czasu wygaśnięcia oraz weryfikacja oświadczenia audience to kroki niezbędne do utrzymania bezpiecznego stanu zabezpieczeń.

Podsumowanie

Opanowanie granicy między tożsamością a autoryzacją pomaga rozwikłać zagadki nowoczesnej architektury chmurowej. Jeśli tokeny ID będą ściśle skupione na potwierdzaniu, kto siedzi przy klawiaturze, a tokeny dostępu będą określać, jakie działania są dozwolone, programiści mogą budować solidne, bezpieczne integracje z platformami takimi jak Microsoft Entra ID. Aby posłuchać kompleksowego omówienia tych zagadnień i poznać działanie nowoczesnych przepływów logowania w ekosystemie Microsoft, zapoznaj się z pełną dyskusją. Posłuchaj całego odcinka i zgłęb dziś mechanizmy tożsamości w chmurze!

Często zadawane pytania

Czy token ID można wykorzystać do wywoływania interfejsów API lub uzyskiwania dostępu do chronionych zasobów?

Nie. Token ID zawiera wyłącznie oświadczenia tożsamości dotyczące użytkownika. Aby wywoływać interfejsy API lub uzyskiwać dostęp do chronionych zasobów, aplikacja musi użyć tokenu dostępu wystawionego za pomocą protokołu OAuth 2.0.

Dlaczego OpenID Connect i OAuth 2.0 używają oddzielnych tokenów?

Rozdzielenie tożsamości od autoryzacji pozwala aplikacjom weryfikować, kto się loguje, bez przyznawania tej aplikacji nieograniczonych uprawnień do modyfikowania danych lub zasobów użytkownika.

Co się stanie, jeśli aplikacja zaakceptuje token ID bez sprawdzenia jego podpisu?

Pominięcie weryfikacji podpisu naraża aplikację na sfałszowane tokeny, ponieważ każdy może wygenerować dowolny ciąg znaków, podając się za prawidłowego użytkownika.

Gdzie w wymianie tokenów występuje wartość „nonce”?

Nonce to losowy ciąg znaków generowany na początku przepływu logowania, osadzany wewnątrz tokenu ID, który pozwala aplikacji zapobiegać atakom typu replay.