Czym jest OAuth? Logowanie przez Google i delegowany dostęp wyjaśnione

OAuth to otwarty standard, który pozwala użytkownikowi dać jednej aplikacji ograniczony dostęp do swojego konta w innej usłudze, bez przekazywania hasła. Gdy klikasz „Połącz Kalendarz Google” i widzisz ekran z pytaniem „Zezwolić tej aplikacji na wgląd w Twoje wydarzenia?”, to właśnie OAuth. Aplikacja dostaje token dokładnie na to, co zatwierdziłeś, który możesz w każdej chwili odwołać. Ta sama mechanika, z dodatkową warstwą o nazwie OpenID Connect, stoi za przyciskiem „Zaloguj się przez Google” i podobnymi.

Dlaczego OAuth ma znaczenie, gdy budujesz z AI

OAuth pojawia się w dwóch typowych sytuacjach przy budowaniu aplikacji:

1. Logowanie społecznościowe. Chcesz, aby użytkownicy mogli „zalogować się przez Google” (albo Apple, Microsoft, GitHub) zamiast zakładać kolejne hasło. Zobacz jak dodać logowanie do aplikacji.
2. Łączenie z kontami użytkowników w innych usługach. Twoja aplikacja musi czytać kalendarz użytkownika, publikować na jego koncie społecznościowym, pobierać pliki z dysku w chmurze albo synchronizować dane księgowe.

W obu przypadkach narzędzie AI może napisać kod, ale niektóre kroki może wykonać tylko Ty: utworzenie aplikacji deweloperskiej u dostawcy, zdobycie client ID i client secret, zarejestrowanie adresów wywołania zwrotnego i — przy niektórych uprawnieniach — przejście weryfikacji dostawcy. Znajomość działania OAuth sprawia, że te kroki — i błędy, które powodują — są dużo mniej tajemnicze. Szerszy obraz logowania znajdziesz w artykule czym jest uwierzytelnianie.

Codzienna analogia

Pomyśl o karcie do pokoju w hotelu. Przy meldunku recepcja potwierdza, kim jesteś, i wydaje kartę, która otwiera Twój pokój i siłownię — nie inne pokoje ani strefy personelu — i przestaje działać przy wymeldowaniu. Karta nie zawiera Twojego paszportu. Jeśli ją zgubisz, recepcja ją unieważnia i wydaje nową.

• Recepcja to serwer autoryzacji (strona logowania Google).
• Sprawdzenie Twojej tożsamości to Twoje logowanie do Google.
• Karta do pokoju to token dostępu.
• „Tylko pokój i siłownia” to zakresy, które zatwierdziłeś.
• Wymeldowanie to wygaśnięcie tokenu lub odwołanie dostępu przez Ciebie.

Aplikacja, z której korzystasz, nigdy nie widzi Twojego hasła do Google, tylko kartę.

Jak działa OAuth, krok po kroku

Najczęstszym przepływem dla aplikacji webowych jest przepływ kodu autoryzacji. Oto, co się dzieje, gdy użytkownik łączy swój Kalendarz Google z aplikacją do rezerwacji terminów:

1. Kliknięcie. Użytkownik klika „Połącz Kalendarz Google”.
2. Przekierowanie do dostawcy. Aplikacja wysyła przeglądarkę do Google z jej client ID, zakresami, których chce (odczyt wydarzeń z kalendarza), i redirect URI, pod które Google ma odesłać użytkownika.
3. Logowanie i zgoda. Użytkownik loguje się do Google (jeśli jeszcze nie jest zalogowany) i widzi ekran zgody z listą tego, o co aplikacja prosi. Klika Zezwól.
4. Powrót z kodem. Google przekierowuje przeglądarkę na redirect URI aplikacji z krótkotrwałym, jednorazowym kodem autoryzacji.
5. Wymiana na serwerze. Serwer aplikacji wysyła ten kod wraz z client secret bezpośrednio do Google i otrzymuje token dostępu (a często token odświeżania).
6. Użycie API. Serwer wywołuje API Kalendarza Google z tokenem dostępu i pobiera wydarzenia użytkownika.

Wywołanie zwrotne z kroku 4 wygląda mniej więcej tak:

https://yourapp.com/auth/google/callback?code=4/0Adeu5B...&state=x7Kq9

A odpowiedź z tokenem w kroku 5 to JSON, na przykład:

{
  "access_token": "ya29.a0Af...",
  "expires_in": 3599,
  "refresh_token": "1//0gL...",
  "scope": "https://www.googleapis.com/auth/calendar.readonly",
  "token_type": "Bearer"
}

Ważny punkt projektowy: wymiana tokenów odbywa się między serwerami, więc client secret i tokeny nigdy nie muszą przechodzić przez przeglądarkę.

OAuth vs OpenID Connect vs własne logowanie

Wiele aplikacji łączy te podejścia: logowanie e-mailem i hasłem, plus „Zaloguj się przez Google” przez OIDC, plus osobne połączenia OAuth z innymi usługami.

Kluczowe pojęcia

Typowe nieporozumienia

• „OAuth to system logowania”. Zwykły OAuth przyznaje dostęp; OpenID Connect obsługuje tożsamość. Używanie gołego tokenu dostępu jako dowodu, kim ktoś jest, spowodowało prawdziwe błędy bezpieczeństwa.
• „Aplikacja dostaje moje hasło”. Nigdy tak nie jest. O to właśnie chodzi.
• „Proszenie o więcej zakresów jest nieszkodliwe”. Użytkownicy są ostrożniejsi wobec szerokich żądań, a dostawcy tacy jak Google mogą wymagać weryfikacji aplikacji przy wrażliwych lub ograniczonych zakresach. Proś tylko o to, czego potrzebujesz.
• „Client secret może trafić do frontendu”. Wszystko, co jest w kodzie przeglądarki, jest publiczne. Trzymaj go w sekretach po stronie serwera.
• „Działa w testach, więc zadziała na produkcji”. Dostawcy często ograniczają niezweryfikowane aplikacje — np. do wymienionych użytkowników testowych — a adres przekierowania dla Twojej żywej domeny trzeba zarejestrować osobno.
• „Tokeny działają wiecznie”. Tokeny dostępu szybko wygasają, a użytkownicy mogą odwołać dostęp. Aplikacja musi sobie z obiema sytuacjami radzić poprawnie.

O co poprosić narzędzie do budowania z AI

• „Dodaj „Zaloguj się przez Google” używając OpenID Connect z dobrze utrzymywaną biblioteką do uwierzytelniania — nie pisz przepływu OAuth od zera.”
• „Używaj przepływu kodu autoryzacji z PKCE i sprawdzaj parametr state.”
• „Czytaj client ID i client secret ze zmiennych środowiskowych po stronie serwera.”
• „Proś tylko o zakresy, których potrzebujemy: dostęp do kalendarza tylko do odczytu.”
• „Wypisz każdy adres przekierowania, który muszę zarejestrować w konsoli dostawcy: dla podglądu, dla opublikowanego adresu i dla mojej własnej domeny.”
• „Przechowuj tokeny odświeżania zaszyfrowane w bazie danych, a wygasłe lub odwołane tokeny obsługuj, prosząc użytkownika o ponowne połączenie.”
• „Pozwól użytkownikom odłączyć integrację na swojej stronie ustawień.”

OAuth a Mythex

Mythex nie ma wbudowanego logowania użytkowników końcowych w aplikacjach, które budujesz; jego dokumentacja opisuje podejście „przynieś własne” — wybierasz bibliotekę uwierzytelniania lub hostowanego dostawcę, zapisujesz jego klucze jako sekrety projektu, a agent pisze kod. Przepis dodawanie uwierzytelniania zawiera gotowy początkowy prompt. Z OAuth spotkasz się też w samym Mythex: możesz zarejestrować się przez Google, połączenie z GitHub do synchronizacji repozytorium używa OAuth GitHub, a asystenci AI łączący się z Mythex przez MCP przechodzą przez stronę zgody OAuth. Więcej znajdziesz w artykułach czym jest uwierzytelnianie i czym jest dwuskładnikowe uwierzytelnianie.

Pytania