Implicit engedélyezési típus az OAuth 2.0-ban

Az Implicit engedélyezési típus, más néven a "token" módszer, elsősorban kliens oldali alkalmazásokhoz lett tervezve, ahol a kliens nem tudja biztonságosan tárolni a kliens titkot. Ilyen alkalmazások az egyoldalas alkalmazások (SPA-k) vagy más böngészőalapú alkalmazások. Ahelyett, hogy egy engedélyezési kódot kapna, amelyet hozzáférési tokenre kell cserélni, az alkalmazás közvetlenül kapja meg a hozzáférési tokent.

Hogyan működik az Implicit engedélyezési típus?

1. Átirányítás:

• A kliens alkalmazás átirányítja a felhasználót az OAuth 2.0 engedélyezési szerver engedélyezési végpontjára. Ez az átirányítás általában tartalmaz lekérdezési paramétereket, mint a client_id, response_type ("token" értékre állítva az Implicit engedélyezéshez), redirect_uri (ahová az engedélyezési szerver a hozzáférés megadása/megtagadása után átirányít) és scope (a kért hozzáférési szint jelzése).

2. Felhasználó hitelesítése:

• A felhasználó bejelentkezik az engedélyezési szerverre (ha még nincs bejelentkezve) és áttekinti a kliens alkalmazás hozzáférési kérelmét.

3. Hozzáférési token kibocsátása:

• Ha a felhasználó megadja a hozzáférést, az engedélyezési szerver visszairányítja a kliens alkalmazásba a megadott redirect_uri-n keresztül. Az átirányítási URI tartalmazza a hozzáférési tokent (és lejáratát) közvetlenül az URL fragment részében.

4. Védett erőforrás elérése:

• A kliens alkalmazás kinyeri a hozzáférési tokent az URL fragmentumból és tárolja (pl. helyi tárolóban vagy munkamenetben). Ezután ezt a tokent használja a felhasználó nevében történő kérésekhez az erőforrás szerveren (API).

Hogyan konfigurálja az Implicit engedélyezési típust?

1. Alkalmazás regisztrálása:

• Kezdje alkalmazása regisztrálásával az OAuth 2.0 szolgáltatónál. Sikeres regisztráció után általában client_id-t kap.

2. Redirect URI beállítása:

• Adjon meg redirect_uri-t a regisztráció során. Az engedélyezési szerver erre az URI-ra irányítja a felhasználókat a hozzáférés megadásának vagy megtagadásának eldöntése után. Győződjön meg arról, hogy ez az URI biztonságos (jellemzően HTTPS-t használ) és képes kezelni a token kinyerését az URL fragmentumból.

3. OAuth folyamat indítása:

• Irányítsa át a felhasználókat az engedélyezési szerver engedélyezési végpontjára a szükséges paraméterekkel. Használjon az alkalmazás nyelvéhez vagy keretrendszeréhez illő könyvtárakat vagy SDK-kat.

4. Token kinyerése és tárolása:

• A visszairányítás után nyerje ki a hozzáférési tokent az URL fragmentumból. Tárolja a tokent biztonságosan, figyelembe véve a kliens oldali tárolási lehetőségeket, mint a Web Storage (localStorage vagy sessionStorage) vagy sütik. Biztosítsa a védelmet a cross-site scripting (XSS) támadások ellen.

5. Token használata:

• Csatolja a hozzáférési tokent az erőforrás szerverre küldött API kérésekhez.

6. Token lejárat kezelése:

• Mivel az Implicit engedélyezés általában nem biztosít frissítési tokeneket, a hozzáférési token lejáratakor előfordulhat, hogy újra el kell indítania az OAuth folyamatot egy új token beszerzéséhez.

Szempontok:

• Biztonság: Az Implicit engedélyezési típus kevésbé biztonságosnak tekinthető, mint az Authorization Code engedélyezési típus, különösen azért, mert a hozzáférési token megjelenik az URL-ben. Ez kockázatot jelenthet olyan környezetekben, ahol az URL-eket naplózzák vagy harmadik felek hozzáférhetnek.

• Nincs frissítési token: Jellemzően az Implicit engedélyezés nem biztosít frissítési tokeneket. Ezért a hozzáférési token lejáratakor az egész folyamatot meg kell ismételni.

• Elavulás: Az inherens biztonsági aggályok miatt az OAuth 2.0 biztonsági legjobb gyakorlatok dokumentuma az Implicit engedélyezés mellőzését javasolja az Authorization Code PKCE-vel (Proof Key for Code Exchange) a nyilvános kliensek, például SPA-k számára.

Összefoglalás:

Bár az Implicit engedélyezési típus egyszerűbb folyamatot kínál kliens oldali alkalmazásokhoz, biztonsági aggályai miatt a modern alkalmazásokban való használata ellen szólnak az ajánlások. Ha új alkalmazásokat épít, különösen SPA-kat, fontolja meg az Authorization Code engedélyezés PKCE-vel történő használatát a biztonságosabb megközelítés érdekében.