Az OAuth 2.0 (kiejtve O-auth) egy nyílt szabványú autorizációs protokoll, ami lehetővé teszi, hogy egy alkalmazás (pl. egy weboldal vagy mobil app) a felhasználó nevében férjen hozzá egy másik szolgáltatáshoz — anélkül, hogy a felhasználónak átadnia kellene a jelszavát. A klasszikus példa a „Bejelentkezés Google-fiókkal” gomb: rákattintasz, átirányít a Google-ra, ott jóváhagyod a hozzáférést, és visszakerülsz az eredeti app-ra, ami most már tudja, ki vagy. A mai web alaprétege — gyakorlatilag minden komoly integráció (Stripe API, Slack bot, Google Calendar sync, social login) OAuth-ot használ.
Így is ismerheted
Magyarul leggyakrabban autorizációs protokoll-ként vagy hozzáférés-engedélyező rendszer-ként fordítják, de gyakorlatilag mindenki az OAuth vagy az OAuth 2.0 nevet használja (az OAuth 1.0 régi, 2010 előtti változat, ma már sehol). Kapcsolódó fogalmak: OIDC (OpenID Connect — az OAuth-ra épülő azonosítási réteg), SSO (Single Sign-On, ami sokszor OIDC-vel valósul meg), access token, refresh token, scope. Ha valaki „SSO-zik a Google-lal”, az nagy valószínűséggel OIDC, ami alatta OAuth.
OAuth vs autentikáció — mi a különbség?
Egy gyakori félreértés: az OAuth NEM autentikációs protokoll. Az autentikáció arra válaszol, hogy „ki vagy” (jelszó, biometrikus adat, SMS-kód). Az OAuth arra, hogy „mit szabad neked tenni más rendszerében”. A kettő közeli, de nem ugyanaz — ezért született az OpenID Connect (OIDC), ami az OAuth-ot kibővíti egy id_token-nel, amiben benne van a felhasználó identitása. Ha „Bejelentkezés Google-lal” gomb van az oldaladon, az valójában OIDC, nem tiszta OAuth.
Praktikus szempontból a fejlesztő ritkán látja a különbséget — a Google, Facebook, GitHub mind OIDC-t implementál az OAuth flow tetején, és a kliens-könyvtárak (pl. NextAuth.js, Passport.js) elrejtik a részleteket. De ha valaki Stripe-bot épít, ami a customer kontóhoz fér hozzá az API-n keresztül, az tiszta OAuth — itt nincs „bejelentkezés”, csak hozzáférés egy másik service-hez.
A négy legfontosabb OAuth-flow
Az OAuth nem egy, hanem több grant flow-t definiál különböző helyzetekre. A mai gyakorlatban négyet érdemes ismerni:
- Authorization Code Flow (with PKCE) — a default mai webes és mobil app-okon. A user átirányítódik a provider-hez, jóváhagyja, kap egy code-ot, amit az app secret-tel cserél access token-re. A PKCE (Proof Key for Code Exchange) extra biztonság, kötelező mobil + SPA-n.
- Client Credentials Flow — szerver-szerver kommunikációra, ha nincs ember a folyamatban (pl. a te backend lekér egy Stripe API kulcsot a saját accountoddal).
- Implicit Flow — régen JS-SPA-knak ajánlott, ma elavult. Helyette PKCE-vel Authorization Code Flow.
- Resource Owner Password Credentials — a user jelszavát átadod az app-nak. Ma már csak legacy esetekben (saját trusted first-party app, ahol a user-experience indokolja).
Tipikus szolgáltatók és OAuth-implementációk
A 2026-os mainstream OAuth-provider piacot a következő szereplők dominálják:
- Google — a legszélesebb körű, OIDC-t is támogat, részletes scope-rendszer (Gmail, Drive, Calendar külön). Hazai e-mail-fiókkal való belépéshez de facto standard.
- Microsoft / Azure AD — vállalati kontextusban király, Office 365 felhasználókhoz alapból megvan.
- Facebook / Meta — még mindig népszerű, főleg consumer app-oknál. Politikai kérdések miatt elveszítette a B2B vonzerejét.
- GitHub — fejlesztő-oldali workflow-khoz (Vercel, Netlify, Heroku login).
- Apple Sign In — iOS app-oknak kötelező, ha más social login is van. Tisztességes privacy-fókusz (relay-email).
- Auth0, Clerk, Supabase Auth — middleware-szolgáltatók, amik az OAuth-bonyolultságot elrejtik egy egységes API mögé. Saját projekten kis-közepes léptékben sokkal hatékonyabbak mint a nulláról építés.
Mire figyelj — biztonság és tipikus hibák
Az OAuth implementáció sokszor azért „kell” mert standard, de néhány alapszabályt elfelejteni katasztrófát okoz. Egy tipikus baki, amit egyik korábbi projekten láttunk: a fejlesztő a state paramétert nem validálta a callback-en, és emiatt a felhasználó támadható volt CSRF-fel — egy gondosan elkészített link automatikusan bekötötte a támadó GitHub-fiókját a célzott user accountjára. Két óra fix volt benne.
Pár alapszabály, amit minden OAuth-integrációnál tartsunk:
- State paraméter — minden auth request-en küldj egy random tokent (state), és a callback-en validáld. Ez véd a CSRF ellen.
- PKCE minden public client-en (mobil app, SPA) — a kliens-secret nélkül is biztonságos.
- HTTPS mindenhol — OAuth callback HTTP-n elfogadhatatlan, ellopható a code.
- Access token rövid élettartam (1 óra), refresh token-nel rotáld. A refresh token lopása lassabb támadás-vektor.
- Scope minimalizálás — kérj csak annyi jogosultságot amennyit használsz. Ha csak az e-mailre kell, ne kérd a Drive read/write-ot.
- Token-tárolás — szerveroldalon httpOnly cookie vagy DB-ben titkosítva. Soha ne localStorage-ben (XSS-en át ellopható).
OAuth implementálás — építsd vagy középes-szolgáltatást?
Saját OAuth-szerver építése (ha te akarsz lenni a provider, és más app-ok jönnek hozzád auth-ot kérni) komoly munka — itt érdemes Keycloak, Auth0 vagy Ory-t használni, nem nulláról. Ha viszont fogyasztó vagy (a te app-od kéri a Google/GitHub-tól az auth-ot), akkor 99% esetben elég egy kliens-könyvtár — NextAuth.js (Next.js), Passport.js (Node.js), Devise/Doorkeeper (Rails), Spring Security (Java), Laravel Socialite (PHP).
WordPress-projekten a WP OAuth Server plugin (ha provider akarsz lenni) vagy a Theme My Login social-login bővítményei (ha consumer) gyors megoldások. Hivatalos szabvány-doksi: oauth.net/2 — érdemes átolvasni, ha komolyabban integrálsz.
Ha OAuth-bekötést, social-login implementációt, vagy egyedi backend-integrációt csinálnánk neked, lásd az egyedi weboldal-fejlesztés szolgáltatásunkat. Kapcsolódó cikkek: Webhook, GraphQL.
