OAuth 2.0 — jak działa protokół autoryzacji w nowoczesnych aplikacjach?

Czym jest OAuth 2.0?

OAuth 2.0 to framework autoryzacyjny^?framework autoryzacyjny: elastyczny zestaw reguł i mechanizmów delegowania dostępu — nie narzuca jednej sztywnej implementacji, co ułatwia adopcję, ale wymaga świadomego projektowania zdefiniowany w dokumencie RFC 6749 przez Internet Engineering Task Force (IETF). Jego podstawowym zadaniem jest bezpieczne delegowanie uprawnień dostępu do zasobów bez konieczności ujawniania hasła użytkownika aplikacjom trzecim.

Standard jest celowo opisywany jako „framework", a nie protokół. Oznacza to, że zapewnia ogólne ramy i mechanizmy, które można implementować na różne sposoby. Ta elastyczność ułatwiła masową adopcję, ale jednocześnie otworzyła przestrzeń dla błędów implementacyjnych.

Kto za tym stoi?

OAuth 2.0 został opracowany pod egidą IETF. Głównym autorem i redaktorem specyfikacji RFC 6749 był Dick Hardt, ekspert ds. tożsamości cyfrowej. Poprzednia wersja, OAuth 1.0, wymagała podpisywania każdego żądania HTTP złożonymi algorytmami kryptograficznymi (HMAC-SHA1, RSA) — co było podatne na błędy i trudne w implementacji. OAuth 2.0 przeniósł odpowiedzialność kryptograficzną na warstwę transportową TLS/HTTPS, drastycznie upraszczając integrację.

Dziś standard utrzymuje IETF OAuth Working Group, która pracuje nad kolejną iteracją — OAuth 2.1 — konsolidującą wszystkie poprawki bezpieczeństwa i usuwającą przestarzałe mechanizmy.

Jak to działa?

Sercem OAuth 2.0 jest wymiana między czterema rolami:

• Właściciel zasobu (Resource Owner) — zwykle użytkownik — posiada dane i może udzielać do nich dostępu.
• Klient (Client) — aplikacja, która chce te dane odczytać lub modyfikować.
• Serwer autoryzacyjny (Authorization Server) — uwierzytelnia właściciela zasobu, zbiera jego zgodę i wystawia tokeny.
• Serwer zasobów (Resource Server) — API lub baza danych z chronionymi zasobami. Weryfikuje tokeny dostępu i na ich podstawie udostępnia dane.

Authorization Code Flow

Przykład: logujesz się do Spotify kontem Google.

1. Klikasz „Kontynuuj przez Google" na stronie logowania Spotify. Spotify przekierowuje Twoją przeglądarkę do Google z parametrami: client_id=spotify, scope=email profile, redirect_uri=https://accounts.spotify.com/callback, state=xyz789.
2. Na stronie Google logujesz się i zatwierdzasz ekran zgody: „Spotify chce dostęp do Twojego imienia i adresu e-mail". Klikasz Zezwól.
3. Google przekierowuje przeglądarkę z powrotem do Spotify z jednorazowym kodem autoryzacji osadzonym w URL: https://accounts.spotify.com/callback?code=SplxlOBeZQ…&state=xyz789. Sam kod nie daje dostępu — potrzebny jest jeszcze tajny klucz Spotify.
4. Serwer Spotify — bez udziału Twojej przeglądarki (back-channel) — wysyła kod i client_secret do Google. W odpowiedzi otrzymuje Access Token i Refresh Token w formacie JSON.
5. Token zostaje na serwerze Spotify — Twoja przeglądarka go nie widzi. Dostajesz ciasteczko sesji (HttpOnly) i lądujesz zalogowany na swoim koncie.
6. Gdy Spotify potrzebuje Twoich danych (np. imienia do wyświetlenia w profilu), jego serwer wysyła żądanie do Google API z nagłówkiem Authorization: Bearer <token>. Google weryfikuje token i zwraca dane.

Rozszerzenie PKCE

PKCE^?PKCE: Proof Key for Code Exchange (RFC 7636) — kryptograficzne rozszerzenie do Authorization Code Flow, które wiąże żądanie autoryzacji z wymianą kodu, zapobiegając atakom przechwycenia dodaje kluczową warstwę ochrony. Przed rozpoczęciem przepływu klient generuje losowy code_verifier, hashuje go SHA-256^?SHA-256: Kryptograficzna funkcja skrótu z rodziny SHA-2. Dla dowolnego wejścia generuje 256-bitowy skrót o stałej długości. Nawet minimalna zmiana danych wejściowych daje całkowicie inny wynik. Używana m.in. w HTTPS, podpisach cyfrowych i OAuth 2.0. jako code_challenge i dołącza do żądania. Przy wymianie kodu na token serwer weryfikuje, czy dostarczony code_verifier odpowiada wcześniejszemu wyzwaniu — gwarantując, że kod może wymienić tylko oryginalny klient.

Poniżej zestawienie głównych grant types z ich statusem:

Z jakich elementów się składa?

Poza czterema rolami kluczowym budulcem OAuth 2.0 są tokeny.

Access Token

Token dostępu to krótkotrwałe poświadczenie (typowo 5–15 minut ważności) wysyłane w nagłówku HTTP przy każdym żądaniu. Może mieć dwa formaty. Opaque Token to losowy ciąg bez wbudowanej treści — serwer zasobów musi odpytać serwer autoryzacyjny (endpoint introspection) przy każdej weryfikacji. JSON Web Token (JWT) to natomiast samodzielny, kryptograficznie podpisany token z ładunkiem (payload) zawierającym claims^?claims: zestaw deklaracji osadzonych w JWT, opisujący właściwości podmiotu i kontekst autoryzacji — m.in. sub (identyfikator użytkownika), iss (wystawca), aud (adresat), exp (wygaśnięcie) i scope (zakres uprawnień). JWT umożliwia lokalną, bezstanową weryfikację bez kontaktu z serwerem autoryzacyjnym.

Refresh Token

Token odświeżania to długowieczne poświadczenie (np. 7–30 dni) do cichego odnawiania Access Tokenów po ich wygaśnięciu — bez ponownego logowania użytkownika. Mechanizm rotacji Refresh Tokenów unieważnia każdy token po użyciu i wystawia nowy, chroniąc przed atakami powtórzenia (Replay Attacks).

Scope

Scope^?Scope: zdefiniowany zakres uprawnień przyznanych klientowi, np. "read:calendar" oznacza wyłącznie odczyt kalendarza bez dostępu do innych danych konta definiuje granice udzielonego dostępu. Drobne, dobrze dobrane zakresy minimalizują ryzyko — aplikacja dostaje dostęp wyłącznie do tego, czego faktycznie potrzebuje.

Do czego może być używane?

OAuth 2.0 napędza większość przypadków delegowanego dostępu w Internecie:

• Federowane logowanie — „Zaloguj przez Google / GitHub / Facebook" na zewnętrznych serwisach. Użytkownik loguje się u dostawcy tożsamości, zewnętrzna aplikacja dostaje ograniczony token.
• Machine-to-Machine (M2M) — komunikacja mikroserwisów bez udziału użytkownika (Client Credentials Flow^?Client Credentials Flow: Przepływ OAuth 2.0 dla komunikacji Machine-to-Machine (M2M). Klient (usługa) uwierzytelnia się bezpośrednio u serwera autoryzacyjnego własnym client_id i client_secret — bez udziału użytkownika. Stosowany w mikroserwisach i pipeline'ach automatycznych.). Usługa autoryzuje się własnym client_id i client_secret.
• Single Sign-On (SSO) w środowiskach korporacyjnych — jeden login dający dostęp do CRM^?CRM: Customer Relationship Management — oprogramowanie do zarządzania relacjami z klientami. Przechowuje historię kontaktów, umowy, dane sprzedażowe i całą komunikację z klientami., e-maila i środowiska deweloperskiego, w tandemie z OpenID Connect.
• Urządzenia bez pełnej klawiatury — IoT, Smart TV i interfejsy CLI używają Device Authorization Flow: urządzenie wyświetla krótki kod, użytkownik autoryzuje z telefonu.

Czym różni się od innych rozwiązań?

Głównym konkurentem OAuth 2.0 w środowiskach korporacyjnych jest SAML 2.0^?SAML 2.0: Security Assertion Markup Language — protokół federacji tożsamości oparty na XML, szeroko stosowany w środowiskach enterprise do Single Sign-On. Wymienia poświadczenia między dostawcą tożsamości (IdP) a dostawcą usług (SP) w formacie XML.. SAML bazuje na XML i jest głęboko zakorzeniony w infrastrukturze enterprise (Active Directory Federation Services^?Active Directory Federation Services: Usługa Microsoft (ADFS) umożliwiająca Single Sign-On między aplikacjami w sieci korporacyjnej a zewnętrznymi serwisami. Działa jako dostawca tożsamości (IdP) i komunikuje się przez protokół SAML 2.0.). OAuth 2.0 posługuje się lżejszym formatem JSON, jest bardziej przyjazny dla urządzeń mobilnych i architektur API-First^?API-First: Podejście projektowania oprogramowania, w którym API jest traktowane jako główny produkt od pierwszego dnia. Interfejsy są projektowane i dokumentowane przed implementacją, co ułatwia integrację i skalowanie systemu.. Wiele organizacji używa obu równolegle — serwer autoryzacyjny może pośredniczyć między aplikacjami OAuth 2.0 a starszymi systemami obsługującymi SAML.

OAuth 1.0^?OAuth 1.0: Poprzednia wersja standardu OAuth (RFC 5849), wymagająca kryptograficznego podpisywania każdego żądania HTTP. Niezgodna z OAuth 2.0, zastąpiona ze względu na złożoność implementacji i trudność w obsłudze urządzeń mobilnych. wymagał podpisywania każdego żądania algorytmami HMAC^?HMAC: Hash-based Message Authentication Code — mechanizm weryfikacji integralności wiadomości łączący funkcję skrótu (np. SHA-256) z tajnym kluczem. Gwarantuje, że wiadomość nie została zmodyfikowana i pochodzi od uprawnionego nadawcy. lub RSA^?RSA: Asymetryczny algorytm kryptograficzny oparty na trudności faktoryzacji iloczynu dużych liczb pierwszych. Używa pary kluczy: publicznego (do szyfrowania i weryfikacji podpisu) i prywatnego (do deszyfrowania i podpisywania). z precyzyjnym sortowaniem parametrów URL — co było podatne na błędy i trudne w implementacji. OAuth 2.0 deleguje bezpieczeństwo kryptograficzne do warstwy transportowej (HTTPS^?HTTPS: HTTP over TLS — szyfrowana wersja protokołu HTTP. Zapewnia poufność (dane nie mogą być podsłuchane), integralność (dane nie mogą być zmodyfikowane w drodze) oraz uwierzytelnienie serwera przez certyfikat SSL/TLS./TLS^?TLS: Transport Layer Security — protokół kryptograficzny zapewniający bezpieczną komunikację w sieci. Następca SSL. Szyfruje połączenie między klientem a serwerem, chroniąc dane przesyłane w tranzycie.), upraszczając integrację.

Najważniejsze ograniczenia i wyzwania

OAuth 2.0 to elastyczny framework, a nie ścisły protokół — i właśnie ta elastyczność jest źródłem jego największych słabości. Poniżej pięć realnych ograniczeń, o których warto wiedzieć projektując systemy autoryzacji.

• Elastyczność bez narzuconych reguł — RFC 6749 nie definiuje formatu tokenów, konkretnych endpointów ani obowiązkowych zachowań. Każdy dostawca implementuje standard inaczej. To ułatwia adopcję, ale prowadzi do niespójnych wdrożeń i pułapek dla programistów przeskakujących między dostawcami tożsamości.
• Tylko autoryzacja — nie uwierzytelnianie — OAuth 2.0 nie potwierdza tożsamości użytkownika. Bezpośrednie użycie Access Tokena jako dowodu „Kim jesteś?" to częsty błąd prowadzący do luk. Do uwierzytelniania potrzebny jest osobny protokół — OpenID Connect (OIDC^?OIDC: OpenID Connect — protokół uwierzytelniania zbudowany na szczycie OAuth 2.0. Odpowiada na pytanie „Kim jesteś?" — po zalogowaniu wystawia ID Token (JWT) zawierający dane użytkownika (imię, e-mail). OAuth 2.0 sam w sobie uwierzytelniania nie zapewnia.).
• Pełna zależność od TLS — cały model bezpieczeństwa OAuth 2.0 spoczywa na warstwie transportowej. Błędna konfiguracja TLS (przestarzałe wersje, słabe szyfry, brak weryfikacji certyfikatu) podważa ochronę niezależnie od poprawności implementacji OAuth.
• Problem unieważniania tokenów JWT — tokeny JWT są bezstanowe i samodzielne: serwer zasobów weryfikuje je lokalnie bez kontaktu z serwerem autoryzacyjnym. To zaleta wydajnościowa, ale uniemożliwia natychmiastowe unieważnienie. Jedyną niezawodną metodą jest server-side blocklist^?server-side blocklist: Lista unieważnionych tokenów prowadzona po stronie serwera. Przy każdym żądaniu serwer sprawdza, czy token nie został unieważniony. Skuteczna, ale wymaga stanu po stronie serwera — co neguje zaletę bezstanowych tokenów JWT. — co niweluje zaletę bezstanowości.
• Fragmentacja ekosystemu — Google, GitHub, Microsoft Entra ID i Auth0 implementują OAuth 2.0 inaczej: różne nazwy endpointów, odmienne zakresy (scope), specyficzne zachowania przy odświeżaniu tokenów. Integracja z wieloma dostawcami tożsamości wymaga obsługi ich specyfiki, nie tylko znajomości RFC 6749.

Zagrożenia i ataki

Nawet poprawnie zaprojektowany system OAuth 2.0 może paść ofiarą błędów implementacyjnych lub celowych ataków. Poniżej opisujemy dwa najczęściej spotykane ataki na warstwę autoryzacji oraz zestaw praktyk, które je skutecznie neutralizują.

Podmiana algorytmu JWT (Key Confusion)

Atakujący modyfikuje algorytm podpisu w nagłówku JWT z RS256 (asymetryczny) na HS256 (symetryczny), a następnie używa publicznie dostępnego klucza publicznego serwera jako symetrycznego sekretu i fałszuje token. Słabo skonfigurowane biblioteki po stronie serwera zasobów mogą zaakceptować taki token. Remedium: jawnie i twardo skonfiguruj akceptowany algorytm weryfikacji po stronie serwera — nigdy nie ufaj polu alg w nagłówku przesłanego tokena.

BOLA (Broken Object Level Authorization)

Atakujący posiada legalny token dla konta A, ale odpytuje endpoint o dane konta B (np. /api/users/12345). Jeśli serwer weryfikuje tylko „czy token jest ważny", a nie „czy ten token należy do właściciela tego zasobu", dochodzi do masowego wycieku danych. Remedium: weryfikacja kontekstowa zasobów — sprawdzenie, czy sub w JWT odpowiada właścicielowi żądanego obiektu.

Podstawowe zasady bezpieczeństwa

• Używaj wyłącznie nowoczesnych przepływów (Authorization Code + PKCE). Implicit Flow i ROPC są oficjalnie wycofane w OAuth 2.1.
• Weryfikuj iss, aud i exp przy każdej walidacji JWT.
• Przechowuj tokeny w ciasteczkach HttpOnly/Secure/SameSite — nie w localStorage (podatne na kradzież przez XSS^?XSS: Cross-Site Scripting — atak polegający na wstrzyknięciu złośliwego kodu JavaScript do strony internetowej. Skrypt wykonuje się w przeglądarce ofiary i może odczytać dane z localStorage, sessionStorage czy ciasteczek pozbawionych flagi HttpOnly.).
• Utrzymuj sztywną białą listę redirect_uri bez użycia wildcard.

OAuth 2.0 w erze agentów AI

Rosnąca popularność agentów AI, wielkich modeli językowych i platform integracyjnych sprawiła, że OAuth 2.0 zyskał nowe, nieoczekiwane pole zastosowania: jest teraz protokołem, który sprawia, że AI może działać w imieniu człowieka — bezpiecznie i z możliwością odwołania uprawnień w dowolnym momencie.

AI API i tokeny Bearer

Większość komercyjnych API modeli AI — OpenAI, Anthropic, Google — nie wymaga pełnego przepływu OAuth 2.0. Dostęp do ich endpointów odbywa się przez statyczny klucz API przesyłany jako token Bearer w nagłówku Authorization. Architektura jest jednak wprost wzorowana na OAuth 2.0: Bearer token w nagłówku, możliwość ustawienia zakresu uprawnień, krótki czas życia kluczy sesyjnych.

OAuth 2.0 w pełnej formie pojawia się tam, gdzie agent AI potrzebuje dostępu do danych konkretnego użytkownika: odczytu Gmaila, modyfikowania dokumentów w Google Drive, pobierania rekordów z Salesforce lub wywoływania API GitHuba. W takich scenariuszach — powszechnych w pipeline'ach RAG i systemach orkiestracji agentów — Authorization Code Flow z PKCE^?PKCE: Proof Key for Code Exchange (RFC 7636) — kryptograficzne rozszerzenie do Authorization Code Flow. Klient generuje losowy code_verifier i jego skrót (code_challenge). Serwer weryfikuje je przy wymianie kodu na token, gwarantując, że tylko oryginalny klient może dokończyć wymianę. jest jedyną architektonicznie poprawną opcją.

Agenci AI, delegacja i problem zgody

Autonomiczny agent AI, który ma zarezerwować spotkanie, odczytać skrzynkę pocztową lub wystawić fakturę, musi działać w imieniu użytkownika. To klasyczny przypadek delegacji uprawnień — i dokładnie ten scenariusz, dla którego OAuth 2.0 został zaprojektowany. W praktyce agenty AI korzystają z dwóch przepływów:

• Authorization Code + PKCE — agent działa w imieniu konkretnego użytkownika. Przykład: asystent AI w CRM^?CRM: Customer Relationship Management — oprogramowanie do zarządzania relacjami z klientami. Przechowuje historię kontaktów, umowy, dane sprzedażowe i całą komunikację z klientami., który odczytuje dane klienta po tym, jak pracownik udzielił zgody przez standardowy ekran OAuth.
• Client Credentials Flow — agent działa w imieniu całej organizacji, nie konkretnej osoby. Przykład: pipeline analityczny pobierający raporty z ERP^?ERP: Enterprise Resource Planning — zintegrowane oprogramowanie zarządzające kluczowymi procesami firmy: finansami, księgowością, magazynem, produkcją, zakupami i HR. Przykłady: SAP, Oracle ERP, Microsoft Dynamics. co noc, bez udziału użytkownika.

Wyzwanie pojawia się przy długich zadaniach agentowych. Access Token wygaśnie po kilku minutach, a użytkownik może już nie być dostępny, żeby ponownie się zalogować. Rozwiązaniem są Refresh Tokeny z rotacją lub architektura Backend-for-Frontend, w której agent korzysta z tokenów sesyjnych zarządzanych po stronie serwera — poza zasięgiem przeglądarki i złośliwych skryptów.

Model Context Protocol i OAuth 2.0

Opublikowana przez Anthropic specyfikacja Model Context Protocol (MCP) — standard komunikacji między agentami AI a narzędziami i serwisami zewnętrznymi — explicite wskazuje OAuth 2.0 jako mechanizm autoryzacji serwera MCP. Gdy agent AI połączony przez MCP chce wywołać narzędzie wymagające uprawnień użytkownika (np. odczytać jego playlistę Spotify lub zmodyfikować plik w Google Docs), serwer MCP inicjuje standardowy przepływ OAuth 2.0.

Dzięki temu agent działa z ograniczonymi, odwoływalnymi uprawnieniami — a nie ze statycznym kluczem API o pełnym dostępie. Użytkownik może w każdej chwili wycofać zgodę w panelu dostawcy tożsamości, co natychmiast uniemożliwia agentowi dalsze działanie. Ten wzorzec — AI jako klient OAuth — jest dziś standardem de facto w ekosystemie integracji agentowych.

Wyzwania bezpieczeństwa w łańcuchach agentów

Wieloagentowe architektury (multi-agent systems) wprowadzają nowe klasy problemów dla OAuth 2.0. Gdy Agent A deleguje zadanie Agentowi B, który z kolei wywołuje Agenta C — kto posiada token? Jaki zakres uprawnień jest przekazywany w dół łańcucha? Czy Agent C może działać z pełnymi uprawnieniami użytkownika, czy tylko z podzbiorem, który Agent A pierwotnie otrzymał?

Branżowe propozycje, takie jak Token Exchange^?Token Exchange: RFC 8693 — mechanizm wymiany tokenów OAuth 2.0, pozwalający agentowi otrzymać token z zawężonym zakresem uprawnień na podstawie istniejącego tokena nadrzędnego (RFC 8693), pozwalają agentom wymieniać tokeny w dół łańcucha z wymuszonym zawężeniem zakresu. Bez tego mechanizmu scope creep staje się realnym ryzykiem: agent z uprawnieniami do odczytu kalendarza może mimowolnie — lub złośliwie — operować w zakresach, których użytkownik nigdy nie zatwierdził.

Czy OAuth 2.0 zostanie wyparte?

OAuth 2.0 ma ponad dekadę, a świat AI i architektur rozproszonych zmienił się radykalnie od czasu jego standaryzacji w 2012 roku. Czy grozi mu obsolescencja?

GNAP^?GNAP: Grant Negotiation and Authorization Protocol (RFC 9635) — protokół autoryzacji zaprojektowany jako następca OAuth 2.0, z natywną obsługą złożonych scenariuszy delegacji i klientów bezserwerowych (Grant Negotiation and Authorization Protocol, RFC 9635) jest najpoważniejszym kandydatem na następcę. Projektowany z myślą o bardziej złożonych scenariuszach delegacji — wieloetapowych negocjacjach, natywnej obsłudze klientów bezserwerowych i lepszej separacji ról — GNAP ma elegancką architekturę. W 2025 roku jednak jego adopcja produkcyjna jest bliska zeru: żaden z głównych dostawców tożsamości (Okta, Auth0, Microsoft Entra ID, Google) nie oferuje jeszcze pełnego wsparcia.

OAuth 2.1 jest bardziej prawdopodobnym „następcą" — to ta sama rodzina protokołów, konsolidująca dekadę poprawek bezpieczeństwa bez przełomowych zmian architektury. Rozszerzenia takie jak DPoP^?DPoP: Demonstrating Proof of Possession (RFC 9449) — rozszerzenie OAuth 2.0, które wiąże token dostępu z konkretnym kluczem kryptograficznym klienta. Nawet jeśli token zostanie skradziony, atakujący nie może go użyć bez prywatnego klucza klienta. (Demonstrating Proof of Possession, RFC 9449) i PAR^?PAR: Pushed Authorization Requests (RFC 9126) — rozszerzenie OAuth 2.0, w którym klient wysyła parametry żądania autoryzacji bezpośrednio do serwera (back-channel), a nie przez URL przeglądarki. Eliminuje ryzyko manipulacji parametrami w front-channel. (Pushed Authorization Requests, RFC 9126) wzmacniają OAuth 2.0 pod kątem agentów AI i środowisk headless.

W kontekście AI: OAuth 2.0 nie tylko nie zostanie szybko wyparty — wzmocni swoją pozycję jako fundament uprawnień w architekturach agentowych. Każda platforma, która integruje AI z danymi użytkownika i dba o bezpieczeństwo, wraca do tych samych primitywów: Authorization Server, zakres uprawnień, krótkotrwały token, możliwość odwołania.

To nie przypadek, że MCP, OpenAI Custom Actions, Microsoft Copilot Extensions i Google Workspace Actions — wszystkie te standardy wskazują OAuth 2.0 jako domyślny mechanizm autoryzacji. Protokół z 2012 roku okazał się wystarczająco elastyczny, żeby stać się fundamentem ery agentów AI.

Dlaczego to jest istotne?

OAuth 2.0 stał się podstawą infrastruktury tożsamości i autoryzacji w nowoczesnym Internecie. Każde logowanie przez konto Google, GitHub czy Apple, każdy integrujący się z danymi serwis zewnętrzny, każda komunikacja między mikrousługami w architekturze cloud-native — wszystko to opiera się na tym standardzie lub na warstwach zbudowanych bezpośrednio na jego fundamentach.

Nadchodząca specyfikacja OAuth 2.1 konsoliduje dekadę poprawek bezpieczeństwa w jednym dokumencie: PKCE staje się obowiązkowe dla wszystkich klientów, Implicit Flow i ROPC znikają ze specyfikacji, a to, co dotychczas było tylko „dobrymi praktykami” wchodzi do normy. Dla każdego, kto projektuje systemy uwierzytelniania i autoryzacji, znajomość OAuth 2.0 — nie jako „skryptu do skopiowania”, ale jako przemyślanej architektury delegowania zaufania — jest fundamentem bezpiecznego wytwarzania oprogramowania.

Jednocześnie warto pamiętać, że sam protokół jest tylko narzędziem. Błędy implementacyjne (nieprawidłowa walidacja claims JWT, brak weryfikacji kontekstowej zasobów, użycie przestarzałych przepływów) mogą podważyć bezpieczeństwo nawet najstaranniej zaprojektowanego systemu. Solidne zrozumienie mechaniki OAuth 2.0 jest tarczą przed najbardziej powszechnymi wektorami ataku na warstwy autoryzacji.

Źródła

• IETF — RFC 6749: The OAuth 2.0 Authorization Framework — link
• IETF — RFC 7636: Proof Key for Code Exchange by OAuth Public Clients — link
• Auth0 / Okta — OAuth 2.0 documentation — link
• OAuth.net — Official OAuth 2.0 resource — link
• IETF — OAuth 2.0 Security Best Current Practice (RFC 9700) — link
• IETF — RFC 8693: OAuth 2.0 Token Exchange — link
• IETF — RFC 9126: OAuth 2.0 Pushed Authorization Requests (PAR) — link
• IETF — RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) — link
• IETF — RFC 9635: Grant Negotiation and Authorization Protocol (GNAP) — link
• OAuth.net — OAuth 2.1 (projekt specyfikacji) — link
• IETF OAuth Working Group — repozytorium robocze — link