Dlaczego Twój produkt potrzebuje OAuth 2.0 i OIDC — Zwłaszcza w erze AI

Od samego początku Logto zbudowano w oparciu o silne przekonanie o otwartych standardach. Zdecydowaliśmy się na stosowanie protokołów takich jak OIDC, OAuth 2.0 i SAML — nie tylko dlatego, że są szeroko stosowane, ale również dlatego, że reprezentują ugruntowane, bezpieczne praktyki zaufane w całej branży. Bezpieczeństwo zawsze było dla nas priorytetem. Podobnie jak wierność duchowi open source i przestrzeganie najlepszych praktyk w zakresie zarządzania tożsamością klientów oraz nowoczesnego uwierzytelniania.

Ale podczas naszej drogi nauczyliśmy się czegoś jeszcze:

OAuth 2.0 i OIDC nie są łatwe dla każdego. Dla programistów, którzy są nowi w tych protokołach, koncepcje mogą wydawać się obce, a czasami wręcz intuicyjnie przeciwne. To spowodowało rzeczywiste wyzwania, gdy pracowaliśmy nad uproszczeniem doświadczenia programisty bez kompromisów w zakresie bezpieczeństwa.

Dwie rzeczy się wyróżniły:

1. Nawet jeśli ciężko pracowaliśmy, aby integracja była jak najbardziej płynna, nadal istnieje krzywa uczenia się dotycząca zrozumienia podstawowych koncepcji, takich jak tokeny ID, tokeny dostępu i jak działają.
2. Powszechne pytanie, które często otrzymujemy, to: "Czy mogę pominąć przekierowanie na ekranie logowania?" Niestety, przekierowanie jest kluczową częścią tego, jak działa OIDC i jest niezbędne dla bezpiecznego uwierzytelniania.

Powszechne pytanie od naszych użytkowników Discord (z ich ID i awatarem ukrytym dla zachowania prywatności).

Każda decyzja niesie z sobą kompromisy — ale czasami wybór, który podjąłeś na początku, okazuje się szczególnie cenny, gdy pojawiają się nowe przypadki użycia. A teraz wchodzimy w nową erę: erę AI.

W tym artykule omówię, kiedy Twój produkt powinien korzystać z OIDC i OAuth 2.0, kiedy może ich nie potrzebować i dlaczego zawsze opowiadałem się za przyjmowaniem tych otwartych standardów od samego początku — zwłaszcza jeśli budujesz realny biznes i wybierasz rozwiązanie CIAM. Wyjaśnię również, dlaczego wzrost znaczenia AI sprawia, że ta decyzja jest teraz ważniejsza niż kiedykolwiek.

Co naprawdę robi OAuth 2.0 (za pomocą prostej analogii)#

Dla czytelników, którzy nie są zbyt zaznajomieni z OAuth 2.0, pozwól, że krótko omówię niektóre z podstawowych koncepcji — aby wszystko było bardziej przejrzyste.

OAuth 2.0 jest dla delegowanego upoważnienia: OAuth 2.0 to standardowy w branży protokół do autoryzacji – pozwala jednej usłudze uzyskać dostęp do zasobów w imieniu innej usługi za zgodą właściciela zasobów.

W scenariuszu OAuth użytkownik (właściciel zasobu) udziela aplikacji klienta ograniczonego dostępu (ogród uprawnień) do interfejsu API lub serwera zasobów, bez udostępniania swojego hasła. OAuth definiuje sposób żądania i wydawania tokenów dostępu, które klient może wykorzystać do wywoływania chronionych interfejsów API. To był przełom w porównaniu z wczesnymi dniami, gdy aplikacje mogły prosić o Twoje dane uwierzytelniające, aby uzyskać dostęp do innej usługi (poważne zagrożenie bezpieczeństwa). Z OAuth 2.0 użytkownicy zatwierdzają określony dostęp, a klient otrzymuje token tylko z potrzebnymi uprawnieniami i czasem trwania — żadne hasła nie są wymieniane, co znacznie poprawia bezpieczeństwo.

Pomyśl o OAuth 2.0 jak o zameldowaniu się w hotelu.

Ty (użytkownik) jesteś właścicielem pokoju (Twoich danych). Ale zamiast dawać komuś klucz do pokoju (Twoje hasło), idziesz do recepcji i prosisz o tymczasową kartę dostępu (token dostępu), która działa tylko dla Twojego gościa lub przyjaciela do wejścia na siłownię lub basen — a nie do całego pokoju.

Obsługa hotelu (system OAuth) wydaje tę ograniczoną kartę z określonymi zasadami:

• Działa tylko na siłownię (określony zasób).
• Jest ważna przez krótki czas.
• Nie pozwala nikomu wejść do Twojego pokoju.

W ten sposób nie musisz oddawać swojego głównego klucza — a system pozostaje bezpieczny, nawet jeśli ktoś inny zdobędzie tę ograniczoną kartę.

Spójrzmy na inny przykład. OAuth 2.0 jest szeroko stosowany w scenariuszu logowania społecznościowego.

Powiedzmy, że zapisujesz się do nowej aplikacji, takiej jak Notion, i zamiast tworzyć nową nazwę użytkownika i hasło, klikasz „Kontynuuj z Google”.

Oto, co dzieje się za kulisami z OAuth 2.0:

1. Zostajesz przekierowany na stronę logowania Google, gdzie się logujesz (jeśli jeszcze tego nie zrobiłeś).

2. Google pyta:

   „Czy zezwalasz tej aplikacji na przeglądanie Twojego podstawowego profilu i adresu e-mail?”

3. Klikasz „Zezwól”, a Google wysyła aplikacji token dostępu.

4. Aplikacja używa tego tokenu do:

   • Potwierdzenia Twojej tożsamości (za pośrednictwem danych profilu i e-maila).
   • Utworzenia lub zalogowania Cię do konta — nigdy nie widząc Twojego hasła Google.

Co naprawdę robi OIDC (za pomocą prostej analogii)#

Teraz przyjrzyjmy się OIDC — nowszemu i bardziej zaawansowanemu standardowi. OpenID Connect ma na celu tożsamość i uwierzytelnianie: to warstwa uwierzytelniająca zbudowana na szczycie OAuth 2.0. Podczas gdy sam OAuth 2.0 nie informuje aplikacji, kim jest użytkownik (chodzi tylko o tokeny dostępu i zakresy), OIDC dodaje standardowy sposób obsługi logowania użytkownika i tożsamości.

Korzystając z OIDC, serwer autoryzacji pełni również rolę dostawcy OpenID (dostawcy tożsamości), który uwierzytelnia użytkownika i wydaje token ID zawierający informacje o użytkowniku (tzw. „roszczenia tożsamości”).

W skrócie, OAuth 2.0 odpowiada na pytanie „Czy ten klient może uzyskać dostęp do tego zasobu?”, a OIDC odpowiada na pytanie „Kim jest użytkownik, który właśnie się zalogował?”. Razem pozwalają Twojej aplikacji zweryfikować tożsamość użytkownika, a następnie używać autoryzowanych tokenów do uzyskiwania dostępu do interfejsów API w imieniu użytkownika.

Użyjmy Hotelowej Analogii, żeby lepiej zrozumieć różnicę między OAuth 2.0 a OIDC.

Wyobraź sobie, że zameldowujesz się w hotelu.

• OAuth 2.0 jest jak proszenie hotelu o pozwolenie dla Twojego przyjaciela na korzystanie z siłowni i basenu w Twoim imieniu.

  Idziesz do recepcji, dajesz pozwolenie, a hotel daje Twojemu przyjacielowi przepustkę dla gościa.

  Hotel nie obchodzi kto jest tym przyjacielem — tylko że ma prawo korzystać z tych obiektów.

  👉 To jest OAuth: „Ta aplikacja może uzyskać dostęp do niektórych moich danych lub usług.”

• OIDC jest jak proszenie hotelu o sprawdzenie kim jest osoba przed przyznaniem dostępu.

  Więc Twój przyjaciel pokazuje również dokument ID — i teraz hotel zna jego imię, status oraz że jest zweryfikowanym gościem.

  👉 To jest OIDC: "To jest, kim jest użytkownik, i teraz jest zalogowany."

Jak Logto wykorzystuje OAuth 2.0 i OpenID Connect (OIDC)#

Kluczowe funkcje uwierzytelniania Logto są zbudowane na OIDC (OpenID Connect)#

W swojej istocie Logto jest dostawcą OpenID Connect (OIDC) — standardu zbudowanego na OAuth 2.0, który koncentruje się na bezpiecznym, nowoczesnym uwierzytelnianiu użytkowników. Logto to profesjonalne rozwiązanie CIAM, gdzie tożsamości są podstawowymi elementami budowlanymi, które zarządzamy.

Zaprojektowaliśmy Logto z bezpieczeństwem jako fundamentem. To oznacza wymuszanie PKCE domyślnie, blokowanie niebezpiecznych przepływów, takich jak przepływ ukryty, i poleganie na przekierowaniu w celu bezpiecznego obsługiwania logowań.

Dlaczego przekierowanie?#

OIDC jest przeznaczone do uwierzytelniania opartego na przeglądarce. To nie tylko wybór techniczny — to kwestia zapewnienia użytkownikom bezpiecznego, jednolitego doświadczenia na różnych platformach. Przekierowanie użytkownika do dostawcy tożsamości (jak Logto, Google czy Microsoft) pomaga to osiągnąć.

Oto, jak wygląda typowy przepływ:

1. Użytkownik klika „Zaloguj się”

   → Twoja aplikacja wysyła go na stronę logowania Logto.

2. Loguje się bezpiecznie

   → To tutaj mają miejsce takie rzeczy jak MFA, biometria czy logowania społecznościowe.

3. Logto odsyła go z powrotem

   → Wraz z bezpiecznym tokenem lub kodem autoryzacji.

4. Twoja aplikacja kończy logowanie

   → Token jest weryfikowany i użytkownik jest zalogowany.

Ten wzorzec może wydawać się prosty, ale przynosi potężne korzyści:

• Twoja aplikacja nie obsługuje bezpośrednio danych uwierzytelniających — co oznacza mniej ryzyk.
• Łatwiej jest dodać funkcje takie jak MFA bez zmiany kodu aplikacji.
• Świetnie działa również na mobilnych urządzeniach:
  • iOS korzysta z ASWebAuthenticationSession
  • Android korzysta z Custom Tabs

A jeśli Twój produkt obejmuje wiele aplikacji, Przekierowanie umożliwia jednolite logowanie — użytkownicy logują się raz i mogą przechodzić między aplikacjami bez problemów.

Logto nie wspiera bezpośredniego zbierania haseł w Twojej aplikacji. To celowe. Przepływ ROPC nie jest zalecany ze względu na najlepsze praktyki bezpieczeństwa OAuth 2.0 dla dobrych powodów — jest mniej bezpieczny i trudniejszy do skalowania.

Logto jest również dostawcą OAuth 2.0/OIDC (dostawcą tożsamości)#

Logto jest czymś więcej niż tylko serwerem uwierzytelniania — jest pełnym OAuth 2.0, OpenID Connect (OIDC) i dostawcą tożsamości (IdP). Oznacza to, że może bezpiecznie zarządzać tożsamościami użytkowników i wydawać tokeny, którym mogą ufać inne aplikacje.

Oprócz zasilania doświadczeń logowania dla Twoich własnych aplikacji, Logto obsługuje również integracje z aplikacjami zewnętrznymi, pozwalając zewnętrznym usługom polegać na Logto jako źródle tożsamości.

Co to oznacza w praktyce?

Jako dostawca tożsamości (IdP), Logto zajmuje się weryfikacją użytkowników, zarządzaniem danymi uwierzytelniającymi i wydaje tokeny autoryzacyjne. Gdy użytkownik się zaloguje, Logto może pozwolić mu na dostęp do różnych aplikacji — nawet od innych dostawców — bez ponownego logowania. To ta sama koncepcja, co "Zaloguj się przez Google" lub "Zaloguj się przez Microsoft".

W tym kontekście istnieją dwa rodzaje aplikacji:

• Aplikacje pierwszej strony: Aplikacje, które tworzysz i w pełni kontrolujesz, zintegrowane bezpośrednio z Logto.
• Aplikacje zewnętrzne: Zewnętrzne usługi zbudowane przez partnerów lub deweloperów spoza Twojej organizacji.

Logto umożliwia Twoim użytkownikom logowanie się do tych aplikacji zewnętrznych przy użyciu ich istniejących kont Logto — tak jak użytkownicy przedsiębiorstw logują się do narzędzi, takich jak Slack, z użyciem poświadczeń Google Workspace. To pozwala na:

• Oferowanie jednolitego logowania (SSO) w całym ekosystemie.
• Budowanie otwartej platformy, na której zewnętrzni deweloperzy mogą dodawać „Zaloguj się przez Logto” do swoich aplikacji.

Kiedy naprawdę potrzebujesz OAuth 2.0 i OIDC?#

1. Jeśli wcześniej korzystasz z Auth0 (lub podobnego): Auth0 już jest dostawcą OAuth 2.0 i OIDC. Zarządza logowaniem użytkowników, wydawaniem tokenów i integruje się z Twoimi interfejsami API lub aplikacjami.
2. Autoryzacja M2M: Serwer do serwera (przepływ poświadczeń klienta) Maszyny (lub usługi backendowe) muszą się bezpiecznie komunikować bez użytkownika.
3. Przepływ urządzeń: Inteligentne telewizory, konsole, urządzenia IoT: Urządzenia, takie jak telewizory czy drukarki, muszą uwierzytelnić użytkownika. Przepływ urządzeń jest częścią OIDC.
4. Masz potrzeby integracyjne: Nie tylko uwierzytelniasz użytkowników — tworzysz ekosystem, w którym zewnętrzne aplikacje, partnerzy lub agenci mogą się zintegrować z Twoją platformą i bezpiecznie uzyskać dostęp do danych użytkowników.

Dlaczego OAuth i OIDC są ważniejsze niż kiedykolwiek w erze AI#

W erze AI widzimy wzrost nowych potrzeb w zakresie integracji i dostępu — zwłaszcza w obszarach takich jak niezależni agenci, inteligentne urządzenia i komunikacja system do systemu. Te trendy sprawiają, że OAuth 2.0 i OIDC są ważniejsze niż kiedykolwiek. Oto kilka przykładów:

1. Zdalne serwery MCP

   Budujesz zdalny serwer MCP (Model Context Protocol) i chcesz, aby zewnętrzni agenci mogli się z nim połączyć. Ci agenci potrzebują bezpiecznego dostępu do żądania kontekstu, wykonywania działań i wymiany danych — wszystko bez naruszania zaufania użytkowników. OAuth zapewnia mechanizm do bezpiecznego delegowania dostępu.

2. Otwieranie swojego produktu na integracje

   Prowadzisz własne usługi biznesowe — powiedzmy narzędzie zarządzania projektami lub platformę dla klientów — i chcesz, aby inne produkty lub agenci mogli się z nim zintegrować. To może oznaczać pobieranie danych, inicjowanie przepływów pracy, lub osadzenie Twoich funkcji w innych środowiskach. OAuth 2.0/OIDC umożliwiają precyzyjne, oparte na tokenach mechanizmy kontroli dostępu bez udostępniania poświadczeń użytkowników.

3. Tworzenie własnego agenta

   Tworzysz agenta AI lub asystenta i chcesz, aby mógł on współdziałać z innymi aplikacjami i serwerami MCP — planując spotkania, wysyłając e-maile, publikując aktualizacje lub wykonując zapytania o dane. To wymaga bezpiecznego, uwierzytelnionego dostępu do usług zewnętrznych. OAuth 2.0 to sposób, w jaki Twój agent uzyskuje autoryzację do działania w imieniu użytkownika.

4. Wzrost liczby inteligentnych urządzeń

   Urządzenia sprzętowe, takie jak tłumacze AI czy inteligentni rejestratorzy notatek na spotkaniach, stają się bardziej zdolne dzięki LLM. A przy niższych kosztach i wyższej wydajności coraz więcej takich urządzeń trafia na rynek. Te urządzenia często potrzebują sposobu na uwierzytelnienie użytkowników i dostęp do usług w chmurze — szczególnie z ograniczonymi interfejsami wejścia. Dlatego przepływy, takie jak przepływ autoryzacji urządzeń OAuth lub walidacja tożsamości oparta na OIDC stają się kluczowe.

Kiedy możesz nie potrzebować OAuth 2.0/OIDC#

Oczywiście są przypadki, gdy możesz nie potrzebować OAuth 2.0 lub OIDC — przynajmniej nie teraz. Innymi słowy, jeśli Twój obecny przypadek użycia jest prosty lub w pełni samodzielny, te protokoły mogą nie przynieść natychmiastowej wartości.

Jednak w miarę rozwoju Twojego produktu lub rozszerzania się ekosystemu, potrzeba OAuth 2.0 i OIDC często staje się znacznie bardziej widoczna w dłuższej perspektywie.

1. Proste, wewnętrzne aplikacje

   Jeśli Twoja aplikacja jest używana tylko przez mały zespół wewnątrz firmy i nie musi integrować się z usługami zewnętrznymi ani udostępniać API, podstawowy system uwierzytelniania oparty na loginie i haśle (np. sesje cookie) może wystarczyć.

2. Brak potrzeby uwierzytelniania użytkowników

   Jeśli Twój produkt nie posiada kont użytkowników ani funkcji świadomych tożsamości — jak publiczna witryna z treścią lub narzędzie serwer do serwera z statycznymi kluczami API — OIDC nie jest potrzebne.

3. Brak potrzeby autoryzacji delegowanej

   OAuth jest najlepszy, gdy potrzebujesz, aby użytkownicy autoryzowali Twoją aplikację do dostępu do ich danych w innym systemie (np. Google Drive). Jeśli nie integrujesz się z zewnętrznymi interfejsami API ani nie tworzysz przepływów multi-service, OAuth dodaje złożoność z niewielką wartością.

4. Pojedyncze środowisko, minimalne ryzyko

   Dla prototypów we wczesnej fazie, MVP, lub wewnętrznych narzędzi testowych, gdzie prostota i szybkość przewyższają potrzeby bezpieczeństwa, możesz opóźnić wdrożenie OAuth/OIDC na później.

Ostateczne myśli na temat wyboru odpowiedniej strategii uwierzytelniania#

Możesz nie potrzebować OAuth 2.0 lub OIDC od razu — i to jest całkowicie w porządku. We wczesnych etapach, proste rozwiązania często wystarczają. Ale gdy Twój produkt rośnie, gdy agenci i AI stają się bardziej zintegrowane z tym, jak budujemy, i gdy Twój ekosystem otwiera się na partnerów oraz zewnętrzne strony, bezpieczne i znormalizowane uwierzytelnianie staje się mniej "miłym dodatkiem" a bardziej "koniecznością".

Zamiast próbować nadrobić później, warto teraz położyć fundament. Przyjęcie OAuth 2.0 i OIDC nie chodzi tylko o rozwiązywanie dzisiejszych problemów — chodzi o przygotowanie się na to, co nadchodzi potem.