Mi az OAuth? A „Bejelentkezés Google-lel” és a delegált hozzáférés magyarázata

Az OAuth egy nyílt szabvány, amely lehetővé teszi, hogy a felhasználó korlátozott hozzáférést adjon egy alkalmazásnak a fiókjához egy másik szolgáltatásnál, anélkül hogy átadná a jelszavát. Amikor rákattintasz a „Google Naptár csatlakoztatása” gombra, és megjelenik egy képernyő, amely megkérdezi: „Engedélyezed, hogy ez az alkalmazás lássa az eseményeidet?”, az OAuth működik. Az alkalmazás pontosan a jóváhagyott dolgokra kap tokent, amelyet bármikor visszavonhatsz. Ugyanez a mechanizmus, kiegészítve az OpenID Connect nevű réteggel, működteti a „Bejelentkezés Google-lel” és a hasonló gombokat.

Miért fontos az OAuth AI-val építve

Az OAuth két gyakori helyzetben jelenik meg alkalmazásépítés közben:

1. Közösségi bejelentkezés. Azt szeretnéd, hogy a felhasználóid a „Bejelentkezés Google-lel” (vagy Apple, Microsoft, GitHub) gombbal lépjenek be, ahelyett hogy újabb jelszót hoznának létre. Lásd: hogyan adj bejelentkezést az alkalmazásodhoz.
2. Csatlakozás a felhasználók fiókjaihoz más szolgáltatásokon. Az alkalmazásodnak olvasnia kell a felhasználó naptárát, posztolnia kell a közösségi fiókjába, fájlokat kell húznia a felhőtárhelyéről, vagy szinkronizálnia kell a könyvelési adatait.

Mindkét esetben az AI-építőd megírhatja a kódot, de néhány lépést csak te tudsz megtenni: fejlesztői alkalmazást létrehozni a szolgáltatónál, megszerezni a kliensazonosítót (client ID) és a klienstitkot (client secret), regisztrálni a visszahívási URL-eket, és bizonyos jogosultságoknál átesni a szolgáltató felülvizsgálatán. Ha tudod, hogyan működik az OAuth, ezek a lépések — és az általuk okozott hibák — sokkal kevésbé lesznek titokzatosak. A bejelentkezés nagyobb képéhez lásd: mi a hitelesítés.

Hétköznapi hasonlat

Gondolj egy szállodai kulcskártyára. Bejelentkezéskor a recepció megerősíti, ki vagy, majd olyan kártyát ad, amely a szobádat és a fitneszterem ajtaját nyitja — nem a többi szobát, nem a személyzeti területeket —, és a kijelentkezéskor megszűnik működni. A kártya nem tartalmazza az útleveledet. Ha elveszíted, a recepció visszavonja, és újat ad.

• A recepció az engedélyezési szerver (a Google bejelentkező oldala).
• Az azonosításod a Google-be való bejelentkezésed.
• A kulcskártya a hozzáférési token.
• „Csak a szoba és a fitneszterem” a jóváhagyott scope-ok.
• A kijelentkezés a token lejárata, vagy a te visszavonásod.

Az alkalmazás, amelyet használsz, soha nem látja a Google-jelszavadat, csak a kulcskártyát.

Hogyan működik az OAuth lépésenként

A webalkalmazások leggyakoribb folyamata az authorization code flow. Így zajlik, amikor egy felhasználó összeköti a Google Naptárát egy időpontfoglaló alkalmazással:

1. Kattintás. A felhasználó rákattint a „Google Naptár csatlakoztatása” gombra.
2. Átirányítás a szolgáltatóhoz. Az alkalmazás a böngészőt a Google-hez küldi a kliensazonosítójával, a kért scope-okkal (naptáresemények olvasása), és a redirect URI-val, ahová a Google visszaküldi a felhasználót.
3. Bejelentkezés és hozzájárulás. A felhasználó bejelentkezik a Google-be (ha még nincs bejelentkezve), és lát egy hozzájárulási képernyőt, amely felsorolja, mit kér az alkalmazás. Rákattint az Allow (Engedélyezés) gombra.
4. Vissza egy kóddal. A Google átirányítja a böngészőt az alkalmazás redirect URI-jára egy rövid életű, egyszer használható authorization code-dal.
5. Csere a szerveren. Az alkalmazás szervere ezt a kódot és a kliensnek a titkát közvetlenül a Google-nek küldi, és egy hozzáférési tokent (gyakran egy frissítő tokennel együtt) kap.
6. API-használat. A szerver a hozzáférési tokennel meghívja a Google Calendar API-ját, és megkapja a felhasználó eseményeit.

A 4. lépésben a visszahívás valahogy így néz ki:

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

Az 5. lépés tokenválasza pedig JSON ilyen formában:

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

A fontos tervezési szempont: a tokencsere szerverről szerverre történik, így a kliensitkot és a tokeneket soha nem kell átvinni a böngészőn.

OAuth vs OpenID Connect vs saját bejelentkezés

Sok alkalmazás kombinálja őket: e-mail és jelszavas bejelentkezés, plusz „Bejelentkezés Google-lel” OIDC-n keresztül, plusz külön OAuth-kapcsolatok más szolgáltatásokhoz.

Kulcsfogalmak

Gyakori tévhitek

• „Az OAuth bejelentkezési rendszer.” A sima OAuth hozzáférést ad; az OpenID Connect kezeli az identitást. Ha puszta hozzáférési tokent használnak annak igazolására, ki valaki, valódi biztonsági hibák keletkeztek.
• „Az alkalmazás megkapja a jelszavamat.” Soha nem kapja meg. Ez a lényeg.
• „Több scope kérése ártalmatlan.” A felhasználók óvatosabbak a széles körű kérésekkel szemben, a szolgáltatók, például a Google, pedig alkalmazás-felülvizsgálatot kérhetnek érzékeny vagy korlátozott scope-okhoz. Csak azt kérd, amire szükséged van.
• „A kliensitok mehet a frontendbe.” A böngészőkódban lévő minden nyilvános. Tartsd szerveroldali titkokban.
• „Tesztelésnél működik, tehát éles környezetben is fog.” A szolgáltatók gyakran korlátozzák a nem ellenőrzött alkalmazásokat — például felsorolt tesztfelhasználókra —, és az éles domained visszahívási URL-jét külön kell regisztrálni.
• „A tokenek örökké élnek.” A hozzáférési tokenek gyorsan lejárnak, a felhasználók pedig visszavonhatják a hozzáférést. Az alkalmazásodnak mindkettőt rendesen kell kezelnie.

Mit kérdezz az AI-építődtől

• „Adj hozzá „Bejelentkezés Google-lel” funkciót OpenID Connecttel, jól karbantartott hitelesítési könyvtárral — ne írd kézzel az OAuth-folyamatot.”
• „Használd az authorization code flow-t PKCE-vel, és ellenőrizd a state paramétert.”
• „A kliensazonosítót és a kliensitkot szerveren, környezeti változókból olvasd be.”
• „Csak a szükséges scope-okat kérd: csak olvasási hozzáférés a naptárhoz.”
• „Sorold fel minden átirányítási URL-t, amelyet regisztrálnom kell a szolgáltató konzoljában: az előnézethez, a közzétett URL-hez és az egyedi domainemhez.”
• „A frissítő tokeneket titkosítva tárold az adatbázisban, a lejárt vagy visszavont tokeneket pedig úgy kezeld, hogy a felhasználót arra kéred, csatlakozzon újra.”
• „Engedd, hogy a felhasználók a beállítási oldalukon leválasszák az integrációt.”

OAuth és a Mythex

A Mythexnek nincs beépített végfelhasználói bejelentkezése az általad épített alkalmazásokhoz; a dokumentációja „hozd a sajátodat” (bring-your-own) megközelítést ír le — te választasz egy hitelesítési könyvtárat vagy hosztolt szolgáltatót, a kulcsait projekt-titkokként tárolod, az ügynök pedig megírja a kódot. Erre van egy kész prompt a hitelesítés hozzáadása recept alatt. Az OAuth-tal magában a Mythexben is találkozhatsz: Google-lel is regisztrálhatsz, a GitHub-kapcsolat a repo-szinkronhoz GitHub OAuth-ot használ, a Mythexhez MCP-n keresztül csatlakozó AI-kliensek pedig egy hozzájárulási oldalon mennek keresztül. Többet a mi a hitelesítés és a mi a kétfaktoros hitelesítés oldalakon találsz.

Kérdések