OAuth 2.0 rozwiązał problem który istniał od początku internetu: jak dać aplikacji dostęp do twoich danych bez podawania jej swojego hasła. Zamiast „oto moje hasło do Gmaila, zrób z nim co chcesz” — OAuth pozwala powiedzieć „daję ci pozwolenie na odczytanie moich maili, nic więcej, przez 30 dni”. Aplikacja dostaje token z ograniczonymi uprawnieniami, nie hasło.
Agenty AI działają w imieniu użytkowników przez serwisy wymagające autoryzacji — Gmail, Google Drive, GitHub, Slack, CRM systemy. Każdy z tych serwisów używa OAuth. Agent musi umieć przeprowadzić flow autoryzacji OAuth — ale w sposób który jest bezpieczny gdy agent działa autonomicznie, bez użytkownika przy ekranie.
Czym jest OAuth dla agentów
OAuth dla agentów to adaptacja standardu OAuth 2.0 do przypadku użycia gdzie autoryzację przeprowadza autonomiczny agent AI działający w imieniu użytkownika — wymagająca rozwiązania problemów specyficznych dla agentów: przechowywania tokenów bez narażenia ich na wyciek przez model językowy, odnowienia tokenów bez interakcji użytkownika, i ograniczenia zakresu uprawnień do minimum potrzebnego dla konkretnego zadania.
Trzy problemy specyficzne dla agentów
Problem 1 — token w kontekście: standardowy agent przechowuje token OAuth w zmiennych środowiskowych lub przekazuje go do kontekstu modelu. Model językowy który ma token w kontekście może go ujawnić przez credential leakage. Rozwiązanie: token powinien być zarządzany przez warstwę pośrednią (vault, secrets manager) i nigdy nie trafiać do kontekstu modelu — agent wywołuje wrapper który używa tokena, nie sam token.
Problem 2 — interactive flow: standardowy OAuth wymaga że użytkownik jest przy ekranie żeby zatwierdzić dostęp w przeglądarce. Agent który działa autonomicznie o 3 w nocy nie może czekać aż użytkownik kliknie „Zezwól”. Rozwiązanie: token jest wystawiany z wyprzedzeniem przez użytkownika, z explicit zakresem uprawnień i limitem czasu. Agent refresh’uje token automatycznie gdy wygasa.
Problem 3 — scope creep: agent który raz dostał szeroki zakres OAuth może używać go do akcji które użytkownik nie zamierzał. Rozwiązanie: PKCE (Proof Key for Code Exchange) i principle of least privilege — agent dostaje token z minimalnym zakresem uprawnień niezbędnym do konkretnego zadania, nie szeroki token „na wszelki wypadek”.
MCP OAuth extension
Specyfikacja MCP 2025-03-26 wprowadza rozszerzenie dla OAuth — serwery MCP mogą teraz wymagać autoryzacji OAuth przed dostępem do narzędzi. Agent który łączy się z serwerem MCP wymagającym OAuth przeprowadza flow autoryzacji i dołącza token Bearer do kolejnych żądań. To pozwala serwerom MCP wymagać że tylko autoryzowani agenci mogą korzystać z ich narzędzi.
Praktyczne wdrożenie
Dla enterprise: Azure Managed Identity i AWS IAM Roles pozwalają agentowi działającemu w środowisku chmurowym uzyskać tokeny bez hardcodowania credentials. Agent „jest” tożsamością, nie „ma” credentials.
Dla aplikacji webowych: standardowy OAuth flow z PKCE, tokeny przechowywane w vault, scope ograniczony do minimum. Nigdy token w zmiennej środowiskowej dostępnej dla modelu.