OAuth 2.1 i OIDC dla agentów AI: client credentials, rotacja tokenów i ciasne zakresy

Agent AI to nie jest człowiek przy przeglądarce. Nie kliknie „Zaloguj przez Google“, nie przepisze kodu z SMS-a i nie zatwierdzi zgody w okienku. A mimo to potrzebuje dostępu do API, baz danych i cudzych usług — często szerszego niż przeciętny pracownik. To wywraca dotychczasowe zasady uwierzytelniania. W tym artykule pokazuję, jak poprawnie osadzić agenta w świecie OAuth 2.1 i OpenID Connect: kiedy sięgnąć po przepływ client credentials, jak rotować tokeny, żeby wyciek nie kończył się katastrofą, i jak projektować zakresy na tyle ciasne, by agent nie mógł zrobić więcej, niż musi.

Jak uwierzytelniać agenta AI w OAuth 2.1 i OIDC — krótka odpowiedź

Agent AI działający bez udziału człowieka (komunikacja między maszynami) uwierzytelnia się w OAuth 2.1 przepływem client credentials: ma własną tożsamość klienta (client_id) i sekret lub — lepiej — klucz prywatny, którym podpisuje żądanie o token dostępu. OIDC dokłada do tego warstwę tożsamości: agent może otrzymać token ID potwierdzający, kim jest i w czyim imieniu działa. O bezpieczeństwie przesądzają trzy decyzje: nadaj agentowi tylko te zakresy (scope), których faktycznie potrzebuje, ustaw tokeny o krótkim czasie życia i rotuj poświadczenia, oraz zawsze wiąż token z konkretnym odbiorcą (audience), żeby skradziony token nie otwierał wszystkich drzwi.

To wszystko. Reszta artykułu to rozwinięcie tych trzech filarów wraz z pułapkami, które najłatwiej przeoczyć przy wdrożeniu.

Czym różni się logowanie agenta od logowania człowieka?

Człowiek loguje się interaktywnie. Przeglądarka przekierowuje go do dostawcy tożsamości, ten pokazuje ekran logowania i zgody, a po zatwierdzeniu odsyła z powrotem z kodem autoryzacyjnym. To klasyczny Authorization Code Flow z PKCE — domyślny i jedyny rekomendowany przepływ dla aplikacji z udziałem użytkownika w OAuth 2.1. Sednem jest tu fizyczna obecność człowieka, który podejmuje decyzję.

Agent takiej obecności nie ma. Działa w nocy, w pętli, na serwerze bez ekranu. Nie da się go „przekierować do logowania“, bo nie ma kogo zapytać o zgodę w czasie rzeczywistym. Dlatego potrzebuje przepływu, w którym sam jest podmiotem zaufanym — uwierzytelnia się własnym poświadczeniem, a nie cudzą sesją.

Tu pojawia się rozróżnienie, które warto mieć z tyłu głowy. Agent może działać na dwa sposoby: we własnym imieniu (zaciąga dane z wewnętrznego API, robi backup, indeksuje pliki) albo w imieniu konkretnego użytkownika (czyta skrzynkę Anny, bo Anna go o to poprosiła). Pierwszy przypadek to czysty client credentials. Drugi wymaga delegacji — agent musi nieść ze sobą dowód, że użytkownik nadał mu uprawnienia, najczęściej przez wcześniejszy przepływ z udziałem człowieka albo wzorzec token exchange. Mieszanie tych dwóch trybów to najczęstsze źródło dziur w uprawnieniach.

Kiedy używać przepływu client credentials?

Przepływ client credentials jest właściwy wtedy, gdy nie ma użytkownika końcowego — agent działa jako autonomiczna usługa. Specyfikacja OAuth 2.0 (RFC 6749, sekcja 4.4) opisuje go wprost jako mechanizm komunikacji między maszynami, gdzie klient jest jednocześnie właścicielem zasobu albo działa poza kontekstem konkretnego użytkownika.

W praktyce wygląda to tak: agent wysyła do serwera autoryzacyjnego żądanie z grant_type=client_credentials, dołącza swoje poświadczenia i listę żądanych zakresów, a w zamian dostaje token dostępu. Żadnych przekierowań, żadnych ekranów zgody, żadnego tokenu odświeżającego — bo i po co, skoro agent może po prostu poprosić o nowy token, kiedy stary wygaśnie.

Czego ten przepływ nie obsłuży: sytuacji, w której agent ma sięgnąć po prywatne dane konkretnej osoby. Client credentials nie niesie tożsamości użytkownika, więc nie nadaje się do delegacji. Jeśli agent ma czytać kalendarz Tomasza, token wydany dla samego agenta nie powinien tego umożliwiać — to byłoby obejście modelu zgód. Wtedy sięga się po Authorization Code Flow (gdy człowiek jest obecny przy konfiguracji) albo po wymianę tokenów (RFC 8693), gdzie agent przedstawia token użytkownika i otrzymuje węższy token zawężony do swojej roli.

Jak uwierzytelnić samego agenta — sekret czy klucz?

Najprostsza droga to client_secret: agent trzyma długi ciąg znaków i przesyła go przy żądaniu o token. Działa, ale ma wadę współdzielonego hasła — kto je przechwyci, ten może podszyć się pod agenta. A sekrety mają brzydki zwyczaj wyciekania: trafiają do repozytoriów, logów, zmiennych środowiskowych zrzucanych do plików.

Bezpieczniejszy wzorzec to uwierzytelnianie kluczem prywatnym — private_key_jwt opisane w specyfikacji OIDC. Agent nigdy nie wysyła sekretu. Zamiast tego podpisuje swoim kluczem prywatnym, który nigdy nie opuszcza maszyny, token (JWT) o krótkim czasie życia, a serwer autoryzacyjny weryfikuje podpis kluczem publicznym, który zna z wyprzedzenia. Klucz prywatny nie opuszcza środowiska agenta, więc nawet przechwycenie ruchu nic nie da napastnikowi.

Trzeci poziom to wiązanie tokenu z kluczem klienta (mTLS lub DPoP, RFC 8705 i 9449). Token przestaje być tokenem na okaziciela — zostaje powiązany z konkretnym kluczem. Skradziony token jest wtedy bezużyteczny bez odpowiadającego mu klucza prywatnego. To dziś najmocniejszy realnie wdrażalny standard dla wrażliwych integracji agentowych.

Metoda poświadczenia	Co wysyła agent	Ryzyko przy wycieku	Kiedy stosować
client_secret	Współdzielony sekret	Wysokie — sekret = pełny dostęp	Prototypy, niski poziom ryzyka
private_key_jwt	Podpisany JWT (klucz zostaje)	Średnie — sam token może być skradziony	Domyślny wybór produkcyjny
mTLS / DPoP	Podpisany JWT + dowód posiadania klucza	Niskie — token bezużyteczny bez klucza	Dane wrażliwe, integracje o wysokim ryzyku

Po co OIDC, skoro client credentials wystarcza do dostępu?

OAuth odpowiada na pytanie „co agentowi wolno robić“ (autoryzacja). OIDC odpowiada na pytanie „kim agent jest“ (tożsamość). To różne warstwy i obie się przydają, choć dla samego dostępu do API faktycznie wystarcza OAuth.

OIDC nadbudowuje nad OAuth token ID — podpisany JWT z poświadczeniami o tożsamości. W świecie agentów wartość OIDC ujawnia się przy audytowaniu i delegacji. Kiedy w logach widnieje samo client_id, trudno odpowiedzieć na pytanie audytora: czy ten agent działał sam z siebie, czy w imieniu użytkownika? Token ID z OIDC potrafi nieść takie informacje w sposób weryfikowalny kryptograficznie — kto jest podmiotem, kto wystawcą, dla kogo token jest przeznaczony i jak długo jest ważny.

Branża dopiero ustala wzorce tożsamości agentów. Pojawiają się propozycje, by token agenta jawnie kodował zarówno tożsamość agenta, jak i tożsamość zlecającego użytkownika, tak żeby system docelowy widział pełen łańcuch odpowiedzialności. Praktyczny wniosek na dziś: jeśli agent działa w imieniu ludzi, nie sprowadzaj go do jednej anonimowej tożsamości technicznej — zachowaj identyfikowalność osoby, która stoi za działaniem, a wraz z nią możliwość rozliczenia.

Jak rotować tokeny, żeby wyciek nie był katastrofą?

Rotacja tokenów to założenie, że poświadczenie prędzej czy później wycieknie — i zaprojektowanie systemu tak, by szkoda była mała i krótkotrwała. Sprowadza się do trzech nawyków.

Krótki czas życia tokenu dostępu. Token ważny pięć minut, który wyciekł, jest groźny przez pięć minut. Token ważny trzydzieści dni jest groźny przez miesiąc. Przy client credentials agent nie potrzebuje długo ważnego tokenu — kiedy stary wygaśnie, po prostu poprosi o nowy. Typowe okno to kilka–kilkanaście minut. Im wrażliwszy zakres, tym krótsze.

Rotacja samych poświadczeń klienta. Token wygasa sam, ale sekret czy klucz prywatny agenta żyją długo. Wprowadź harmonogram ich wymiany i — co ważniejsze — możliwość wymiany nakładkowej: nowy klucz zaczyna działać, zanim stary przestanie, więc rotacja nie kładzie usługi. Klucze trzymaj w menedżerze sekretów albo module HSM, nigdy w kodzie ani w obrazie kontenera.

Natychmiastowe unieważnienie. Krótki czas życia nie zastępuje przycisku awaryjnego. Musisz móc w sekundę odebrać agentowi dostęp — przez listę unieważnień, introspekcję tokenu po stronie serwera (RFC 7662) albo wyłączenie klienta. Jeśli jedyną reakcją na incydent jest „poczekajmy, aż token wygaśnie“, to nie masz kontroli, tylko nadzieję.

Token odświeżający (refresh token) przy client credentials jest zbędny i bywa wręcz szkodliwy — to kolejne poświadczenie o długim czasie życia, którego trzeba pilnować. OAuth 2.1 nie przewiduje go w tym przepływie i słusznie. Agent maszynowy nie potrzebuje „pamiętać“ sesji; potrzebuje umieć wystąpić o świeży token, kiedy go zabraknie.

Jak projektować ciasne zakresy dla agentów AI?

Zakres (scope) to deklaracja, co agentowi wolno. Ciasny zakres to taki, który pozwala wykonać zadanie — i ani jednej rzeczy więcej. To bezpośrednie zastosowanie zasady najmniejszych uprawnień, a przy agentach AI ma ona ostrzejsze znaczenie niż przy zwykłych usługach. Agent potrafi działać kreatywnie i nieprzewidzianie; jeśli da mu się szeroki zakres „na wszelki wypadek“, to ten wypadek prędzej czy później nastąpi.

Kilka praktycznych reguł, które się sprawdzają.

Rozdziel odczyt od zapisu. Agent, który ma streszczać dokumenty, potrzebuje documents:read, a nigdy documents:write ani documents:delete. Najbardziej kosztowne pomyłki agentów to operacje destrukcyjne wykonane „w dobrej wierze“. Jeśli zakres na to nie pozwala, najgorszy błąd kończy się na niczym.

Jeden agent, jedno zadanie, jedna tożsamość klienta. Kuszące jest mieć jednego „superagenta“ z dostępem do wszystkiego. To pojedynczy punkt awarii o ogromnym promieniu rażenia. Lepiej rozbić go na osobnych klientów o wąskich zakresach — agent raportujący osobno od agenta piszącego do CRM. Wyciek dotyka wtedy jednego wycinka, nie całości.

Wiąż token z odbiorcą (audience). Token wydany dla API fakturowego nie powinien być przyjmowany przez API kadrowe. Parametr audience (lub resource z RFC 8707) zawęża token do konkretnej usługi. Bez tego skradziony token staje się uniwersalnym kluczem do wszystkich API, które ufają temu samemu serwerowi autoryzacyjnemu.

Zakresy parametryzowane, gdy to możliwe. Zamiast files:read rozważ files:read:projekt-alfa. Im węższa granica, tym mniejsza szkoda po przejęciu. Nie każdy serwer autoryzacyjny to wspiera, ale gdzie się da — warto zejść poniżej poziomu „cały zasób“.

Egzekwuj zakres po stronie zasobu, nie tylko przy wydaniu tokenu. Serwer autoryzacyjny może wydać token z zakresem payments:read, ale to API płatności musi sprawdzić ten zakres przed zwróceniem danych. Zakres, którego nikt nie weryfikuje, jest tylko ozdobą.

Najczęstsze błędy przy wdrażaniu agentów w OAuth

Pierwszy: traktowanie tokenu agenta jak hasła administratora. Agent dostaje szerokie uprawnienia „żeby działał“, a potem nikt ich nie zawęża. To zaprzeczenie sensu OAuth.

Drugi: client credentials tam, gdzie potrzebna delegacja użytkownika. Agent sięga po prywatne dane osób, używając własnej tożsamości technicznej, omijając w ten sposób cały model zgód. Kiedy później ktoś pyta, na jakiej podstawie agent czytał czyjąś skrzynkę, odpowiedzi nie ma.

Trzeci: sekrety w kodzie i logach. Klucz w repozytorium albo wypisany do logu przy debugowaniu to klasyk. Stąd nacisk na klucze prywatne zamiast sekretów i na menedżery sekretów zamiast zmiennych środowiskowych w postaci jawnej.

Czwarty: brak rozróżnienia tożsamości w łańcuchu wywołań. Agent woła kolejnego agenta, ten woła API — a w logach wszystko wygląda jak jedna anonimowa usługa. Kiedy coś pójdzie nie tak, nie da się odtworzyć, kto zlecił operację. Propagacja tożsamości przez wymianę tokenów rozwiązuje to u źródła.

Piąty: tokeny na okaziciela do operacji wysokiego ryzyka. Dla przelewów, zmian uprawnień czy usuwania danych token, który działa „dla każdego, kto go ma“, jest za słaby. Tam należy wiązać token z kluczem (DPoP/mTLS).

Od czego zacząć wdrożenie krok po kroku

Najprostsza sensowna ścieżka wygląda tak. Po pierwsze, rozstrzygnij, czy agent działa we własnym imieniu (client credentials) czy w imieniu użytkownika (delegacja). To decyzja architektoniczna, nie szczegół. Po drugie, nadaj agentowi osobną tożsamość klienta i uwierzytelniaj go kluczem prywatnym (private_key_jwt), nie współdzielonym sekretem. Po trzecie, wypisz dokładnie operacje, które agent ma wykonywać, i przełóż je na minimalne zakresy — z rozdziałem odczytu i zapisu. Po czwarte, ustaw krótki czas życia tokenu i przygotuj procedurę unieważnienia, zanim będzie potrzebna. Po piąte, wymuś weryfikację zakresu i odbiorcy po stronie każdego API, a nie tylko zaufaj temu, co wydał serwer autoryzacyjny.

Żaden z tych kroków nie jest egzotyczny — to dobrze znane praktyki OAuth, tylko zastosowane konsekwentnie do podmiotu, który nie śpi, działa szybko i potrafi zaskoczyć. Dobrze zaprojektowana tożsamość agenta nie jest dodatkiem do systemu AI. Jest tą częścią, która decyduje, czy incydent skończy się na jednym wąskim wycieku, czy na utracie kontroli nad wszystkim, do czego agent miał dostęp.

Standardy, do których warto sięgnąć

• OAuth 2.1 — konsoliduje dobre praktyki OAuth 2.0, wycofuje ryzykowne przepływy, czyni PKCE i krótkie tokeny domyślnymi.
• RFC 6749, sekcja 4.4 — definicja przepływu client credentials.
• RFC 8693 — wymiana tokenów (token exchange), podstawa delegacji i zawężania uprawnień w łańcuchu wywołań.
• RFC 8705 (mTLS) i RFC 9449 (DPoP) — wiązanie tokenu z kluczem klienta.
• RFC 8707 — wskazanie odbiorcy zasobu (resource), zawężanie tokenu do usługi.
• OpenID Connect Core — warstwa tożsamości nad OAuth, w tym private_key_jwt.

To są źródła pierwotne. Przy wdrożeniu produkcyjnym czytaj je wprost, a nie tylko streszczenia — diabeł przy tożsamości agentów siedzi w szczegółach walidacji.