Co się zmieniło, a co nie w Autoryzacji i Tożsamości dla aplikacji agencyjnych
W miarę jak agenty AI stają się coraz bardziej zdolne i połączone, budowanie bezpiecznych i skalowalnych produktów agencyjnych wymaga solidnych podstaw w zakresie uwierzytelniania i tożsamości. Ten przewodnik rozkłada na czynniki pierwsze, co się zmieniło, co nie, i co każdy budowniczy powinien wiedzieć, aby odnaleźć się w nowym krajobrazie.
GuamianProduct & Design
Przestań tracić tygodnie na uwierzytelnianie użytkowników
Uruchamiaj bezpieczne aplikacje szybciej z Logto. Zintegruj uwierzytelnianie użytkowników w kilka minut i skup się na swoim głównym produkcie.
Niedawno przeglądałem ten artykuł i wspomniano w nim o autoryzacji agentów:
Widzimy wskazówki, jak to może wyglądać. Najnowsza specyfikacja MCP, na przykład, obejmuje framework autoryzacyjny oparty na OAuth 2.1, co sygnalizuje możliwość przejścia w stronę dawania agentom AI ograniczonych, odwoływanych tokenów zamiast surowych sekretów. Możemy sobie wyobrazić scenariusz, w którym agent AI nie dostaje twoich rzeczywistych kluczy AWS, ale zamiast tego otrzymuje krótkoterminowe poświadczenie lub token zdolności, który pozwala mu wykonywać ściśle określoną akcję.
Wielu przyjaciół i osób spoza dziedziny bezpieczeństwa lub CIAM ma wrażenie, że to coś nowego, ale zdecydowanie tak nie jest. OAuth jest standardowym protokołem autoryzacji opartym na tokenach, który obejmuje tokeny z określonymi uprawnieniami (akcesowe tokeny). Mają one ograniczony czas działania i zakres, co zapewnia bezpieczeństwo i właściwą kontrolę dostępu do zasobów i usług. Na globalnym rynku SaaS (przed erą AI) większość profesjonalnych rozwiązań tożsamości opiera się już na tym.
Kiedy łączysz swoje konto Google z aplikacją trzeciej strony, taką jak Notion czy Zoom, używa się OAuth do żądania jedynie niezbędnych uprawnień, takich jak dostęp do kalendarza czy kontaktów, bez ujawniania twojego hasła do Google. Możesz w każdym momencie cofnąć ten dostęp w ustawieniach konta Google. Ten wzorzec dostępu delegowanego jest dokładnie tym, do czego został zaprojektowany OAuth i jest tą samą podstawą rozszerzaną obecnie na aplikacje agencyjne.
MCP koncentruje się na interakcji między LLM a narzędziami i kontekstem aplikacji.
A2A koncentruje się na umożliwieniu wymiany zadań między agentami.
Ale jeśli chodzi o uwierzytelnianie i autoryzację, oba nadal opierają się na dobrze ugruntowanych standardach branżowych, takich jak OAuth.
Serwery autoryzacyjne MCP MUSZĄ implementować OAuth 2.1 z odpowiednimi środkami bezpieczeństwa zarówno dla klientów zaufanych, jak i publicznych.
Klient A2A jest odpowiedzialny za uzyskanie niezbędnych materiałów uwierzytelniających (np. tokeny OAuth 2.0, klucze API, JWT) poprzez procesy zewnętrzne w stosunku do samego protokołu A2A. Może to obejmować przepływy OAuth (kod autoryzacji, poświadczenia klienta), bezpieczne dystrybucje kluczy itp.
Jak mówi Google:
Zamiast wymyślać nowe, zastrzeżone standardy dla bezpieczeństwa i operacji, A2A dąży do bezproblemowej integracji z istniejącą infrastrukturą przedsiębiorstwa i szeroko przyjętymi najlepszymi praktykami.
Dużo hype'u i treści FOMO promuje pomysł, że w miarę jak agenty stają się coraz bardziej powszechne, potrzebujemy systemu do zarządzania tożsamościami agentów.
Odpowiedź brzmi: tak i nie.
Tak, ponieważ wprowadzamy nową warstwę między ludźmi a maszynami. Istnieją realne potrzeby:
Zarządzanie i identyfikacja agentów
Przypisywanie unikalnych ID
Śledzenie dzienników
Audyt działania (aby wiedzieć, czy zadanie wykonał człowiek czy agent)
Jednak w większości przypadków technicznych nie ma potrzeby tworzenia formalnego pojęcia „Tożsamości Agenta”.
Agent ≠ Użytkownik, ≠ Konto serwisowe.
Za każdym agentem stoi użytkownik i tożsamość użytkownika zazwyczaj wystarczy.
Dziś większość agentów:
Działa na podstawie autoryzacji użytkownika (np. tokeny OAuth)
Wykonuje logikę lub dokonuje wywołania API
Wykonuje krótkotrwałe, jednorazowe zadania (bez potrzeby śledzenia)
W tym sensie agent jest po prostu funkcją jako narzędziem i nie potrzebuje globalnie unikalnego ID.
Na przykład:
Agent GPT wywołujący twoje API Kalendarza potrzebuje tylko dostępu, który mu przyznałeś.
Agent LangChain nie potrzebuje tożsamości, o ile może wywołać odpowiednie narzędzia, to działa.
M2M oznacza automatyczną wymianę danych między usługami, bez udziału człowieka.
W tym kontekście uwierzytelnianie często używa aplikacji klienckiej lub konta usługi.
Jeśli naprawdę chcesz, aby twój agent miał tożsamość (dla audytu, itp.), możesz użyć ID aplikacji i to wystarczy.
Nadal musisz zdefiniować architekturę swojego produktu#
To się nie zmieniło. Niezależnie od tego, czy twój produkt obejmuje agenty, architektura twojego systemu tożsamości zależy od tego, kim są twoi użytkownicy i jak twój system z nimi współdziała.
Jeśli budujesz produkt agencyjny skierowany do konsumentów:
Potrzebujesz lekkich metod logowania (email, telefon, logowanie społecznościowe) i zjednoczonej puli użytkowników do zarządzania osobami, które korzystają z twojej aplikacji i jej agentów. Agenty działają w imieniu tych użytkowników, używając delegowanych tokenów (np. za pośrednictwem OAuth).
Przykład:
Wyobraź sobie, że budujesz asystenta harmonogramu AI lub bota kalendarza opartego na AI.
Każdy użytkownik loguje się swoim osobistym kontem Google. Twój system używa OAuth, aby uzyskać pozwolenie na dostęp do ich kalendarza. Agent nie ma własnej tożsamości, korzysta z tokena użytkownika do planowania spotkań, sprawdzania dostępności czy wysyłania przypomnień. Architektura tożsamości jest prosta: jedna globalna pula użytkowników, przechowywanie tokenów i śledzenie zgody na użytkownika.
Jeśli budujesz platformę agencyjną B2B:
Musisz wspierać tożsamość na poziomie organizacji, nie tylko pojedynczych użytkowników. Obejmuje to:
SSO dla klientów korporacyjnych
Separacja poziomu workspace lub najemcy
Polityki delegacji agentów na poziomie organizacji (np. kontrolowanie, co agenty mogą robić w różnych zespołach)
Wizualizacja na poziomie administracyjnym i dzienniki dla wszystkich działań agenta w imieniu pracowników
Przykład:
Wyobraź sobie, że budujesz platformę, która dostarcza agentów AI do automatyzacji wewnętrznych przepływów pracy — jak bot analityka bezpieczeństwa, który monitoruje dzienniki i wysyła alerty, czy asystent sprzedaży, który tworzy maile na podstawie danych CRM.
Każda firma, która korzysta z twojej platformy, chce:
Logować się przy użyciu istniejącego SSO
Kontrolować, do czego agenty mogą mieć dostęp (np. narzędzia wewnętrzne, systemy dokumentów)
Zobaczyć, który agent wykonał jakie zadanie, pod jakim upoważnieniem pracownika
W tym przypadku twoja architektura tożsamości musi wspierać projekt multi-tenantowy, ograniczone uprawnienia agentów i polityki specyficzne dla organizacji. Agenty nadal działają w imieniu użytkowników, ale uprawnienia i granice tożsamości są egzekwowane na poziomie biznesowego najemcy.
W obu przypadkach model tożsamości definiuje, jak działają agenty, do czego mają dostęp i jak twój system zapewnia odpowiedzialność.
Skorzystaj z tego przewodnika, aby pomóc w planowaniu architektury tożsamości i produktu.
Zapobiega nieautoryzowanemu dostępowi, nawet jeśli poświadczenia zostaną skompromitowane.
Przykład: Jeśli agent pomaga ci wykonać działanie wysokiego ryzyka, jak dokonanie transakcji lub zmiana ustawień tożsamości, powinien trzymać człowieka w zakresie decyzji i użyć MFA do potwierdzenia działania przed kontynuacją.
Zapewnia, że użytkownicy i agenty mają dostęp tylko do tego, na co mają pozwolenie.
Przykład: Asystent AI w środowisku pracy może czytać wydarzenia z kalendarza, ale nie może uzyskać dostępu do danych rozliczeniowych, chyba że jest mu przypisana wyższa rola.
Poprawia UX i zmniejsza ryzyko stosowania słabych haseł.
Przykład: Pozwól użytkownikom logować się używając magicznego linku wysłanego na ich email lub biometrycznego przypomnienia jak rozpoznawanie twarzy.
Te funkcje dotyczą zarówno tradycyjnych, jak i opartych na agentach aplikacji, szczególnie gdy agenty zaczynają działać w zakresie wrażliwych danych i systemów.
W miarę pojawiania się agentów i złożonych przepływów pracy, widzimy nowe przypadki użycia, w których użytkownicy, agenty, API i serwery MCP wchodzą w interakcje. Liczba i różnorodność tych scenariuszy rośnie szybko, znacznie bardziej niż w przeszłości.
Kiedy te połączenia się zdarzają, autoryzacja staje się bardziej widoczna niż kiedykolwiek. Użytkownicy muszą wyrażać wyraźną zgodę, a uprawnienia muszą być starannie zarządzane w różnych systemach. Dlatego wszyscy teraz mówią o utrzymaniu „człowieka w zakresie decyzji” upewnieniu się, że użytkownicy mają wystarczającą kontrolę i wgląd w to, co agenty mogą robić i jakie zakresy są dla nich autoryzowane.
Twoja aplikacja AI może potrzebować integracji z wieloma zewnętrznymi usługami#
Ekosystem MCP się rozrasta, co oznacza, że twoja aplikacja nie jest już tylko samodzielną usługą: jest częścią większej, połączonej sieci.
Aby dostarczać bogaty, użyteczny kontekst do LLM, twoje agenty mogą potrzebować:
Dostępu do wielu serwerów MCP
Przykład: Wyobraź sobie AI managera projektów, który pobiera aktualizacje zadań z Jiry, dostępność zespołu z Kalendarza Google i dane sprzedażowe z Salesforce, a każdy z tych elementów może być obsługiwany przez inny serwer MCP. Aby wygenerować jeden tygodniowy raport, agent musi bezpiecznie wchodzić w interakcje z wieloma źródłami danych. To tutaj wchodzą w grę uwierzytelnianie i autoryzacja, aby chronić każde połączenie i kontrolować, jak dane są udostępniane.
Połączenie z zewnętrznymi interfejsami API i narzędziami
Przykład: Agent wsparcia klienta może potrzebować pobrać historię zamówień ze Shopify, zaktualizować zgłoszenia w Zendesk i uruchomić przepływy pracy w Slacku. Bez integracji agent staje się odizolowany i nieskuteczny.
W miarę jak agenty przejmują coraz więcej odpowiedzialności, integracja staje się kluczem do użyteczności. Twój produkt AI nie polega tylko na tym, co może zrobić sam i chodzi o to, do czego może mieć dostęp, co może orkiestrować i nad czym może się zastanawiać w połączonym ekosystemie. Dlatego budowanie dla interoperacyjności, w sposób bezpieczny i elastyczny, jest ważniejsze niż kiedykolwiek.
Musisz przyjąć otwarte standardy: OAuth/OIDC są ważniejsze niż kiedykolwiek#
W erze AI potrzeba bezpiecznych, elastycznych integracji rośnie. To sprawia, że OAuth 2.0 i OIDC są ważniejsze niż kiedykolwiek.
Kluczowe przypadki użycia obejmują:
Zdalne serwery MCP: Pozwalaj agentom zewnętrznym bezpiecznie uzyskać dostęp do twojego produktu za pomocą delegowanych tokenów.
Integracje zewnętrzne: Pozwalaj innym narzędziom lub agentom na połączenie się z twoją aplikacją (np. platformą do zarządzania projektami) bez potrzeby używania surowych poświadczeń.
Rozwój agentów: Buduj agenty AI, które bezpiecznie działają w imieniu użytkowników w różnych usługach.
Inteligentne urządzenia: Używaj OAuth/OIDC do rzeczy jak AI-powered note-takery, do uwierzytelniania użytkowników i połączenia z chmurą - zwłaszcza przy minimalnym interfejsie użytkownika.
Te protokoły zapewniają bezpieczny, oparty na tokenach, zatwierdzony przez użytkownika dostęp.
To jest kluczowe w świecie agencyjnych, połączonych systemów. Sprawdź ten artykuł, aby zobaczyć dlaczego OAuth i OIDC są ważne
Projektowanie dla zaufania i skali w erze oprogramowania agencyjnego#
W miarę jak produkty agencyjne się rozwijają, podstawowe zasady tożsamości i autoryzacji pozostają takie same, ale kontekst się zmienia. Agenty wprowadzają nowe powierzchnie dla delegacji, zgody i dostępu. Dlatego trzymanie się otwartych standardów jak OAuth, budowanie klarownej architektury i wdrażanie solidnych praktyk bezpieczeństwa nie są po prostu najlepszymi praktykami, są podstawowe. Projektowanie z ostrożnością teraz oznacza, że twój system będzie się skalować z zaufaniem, elastycznością i pewnością w przyszłości napędzanej przez AI.
