Implicit Grant Type i OAuth 2.0

Implicit Grant Type, även känd som "token"-metoden, utformades primärt för klientsideapplikationer där klienten inte säkert kan lagra en klienthemlighet. Sådana applikationer inkluderar ensidiga appar (SPA:er) eller andra webbläsarbaserade applikationer. Istället för att ta emot en auktoriseringskod som behöver bytas mot en åtkomsttoken får applikationen åtkomsttoken direkt.

Hur fungerar Implicit Grant Type?

1. Omdirigering:

• Klientapplikationen omdirigerar användaren till OAuth 2.0-auktoriseringsserverns auktoriseringsendpoint. Denna omdirigering inkluderar vanligtvis frågeparametrar som client_id, response_type (inställd på "token" för Implicit Grant), redirect_uri (dit auktoriseringsservern omdirigerar efter beviljande/nekande av åtkomst) och scope (som anger den begärda åtkomstnivån).

2. Användarautentisering:

• Användaren loggar in på auktoriseringsservern (om inte redan inloggad) och granskar åtkomstbegäran från klientapplikationen.

3. Utfärdande av åtkomsttoken:

• Om användaren beviljar åtkomst omdirigerar auktoriseringsservern dem tillbaka till klientapplikationen via den angivna redirect_uri. Omdirigerings-URI:n inkluderar åtkomsttoken (och dess utgångstid) direkt i fragmentdelen av URL:en.

4. Åtkomst till skyddad resurs:

• Klientapplikationen extraherar åtkomsttoken från URL-fragmentet och lagrar den (t.ex. i local storage eller en session). Den använder sedan denna token för att göra förfrågningar till resursservern (API:et) på användarens vägnar.

Hur konfigurerar man Implicit Grant Type?

1. Registrera din applikation:

• Börja med att registrera din applikation hos OAuth 2.0-leverantören. Du får vanligtvis en client_id efter lyckad registrering.

2. Redirect URI-konfiguration:

• Ange en redirect_uri vid registrering. Auktoriseringsservern omdirigerar användare till denna URI efter att de beslutat om att bevilja eller neka åtkomst. Säkerställ att denna URI är säker (vanligtvis med HTTPS) och kan hantera tokenextraktion från URL-fragmentet.

3. Starta OAuth-flödet:

• Omdirigera användare till auktoriseringsserverns auktoriseringsendpoint med nödvändiga parametrar. Använd bibliotek eller SDK:er som passar din applikations språk eller ramverk.

4. Extrahera och lagra token:

• När du omdirigerats tillbaka, extrahera åtkomsttoken från URL-fragmentet. Lagra token säkert, med hänsyn till klientsidiga lagringsalternativ som Web Storage (localStorage eller sessionStorage) eller cookies. Säkerställ att den är skyddad mot cross-site scripting (XSS)-attacker.

5. Använd token:

• Bifoga åtkomsttoken till API-förfrågningar som görs till resursservern.

6. Hantera tokenutgång:

• Eftersom Implicit Grant vanligtvis inte tillhandahåller refresh tokens kan du behöva starta OAuth-flödet igen för att erhålla en ny när åtkomsttoken löper ut.

Överväganden:

• Säkerhet: Implicit Grant Type anses vara mindre säkert än Authorization Code Grant Type, särskilt eftersom åtkomsttoken exponeras i URL:en. Detta kan vara en risk i miljöer där URL:er kan loggas eller nås av tredje parter.

• Ingen refresh token: Vanligtvis tillhandahåller Implicit Grant inte refresh tokens. Därför kan hela flödet behöva upprepas när en åtkomsttoken löper ut.

• Utfasning: På grund av de inneboende säkerhetsproblemen rekommenderar OAuth 2.0 Security Best Current Practice-dokumentet att undvika Implicit Grant till förmån för Authorization Code med PKCE (Proof Key for Code Exchange) för publika klienter, som SPA:er.

Slutsats:

Även om Implicit Grant Type erbjuder ett enklare flöde för klientsideappar har dess säkerhetsproblem lett till rekommendationer mot dess användning i moderna applikationer. Om du bygger nya applikationer, särskilt SPA:er, överväg att använda Authorization Code Grant med PKCE för en säkrare metod.