Implicit Grant Type in OAuth 2.0

The Implicit Grant Type, also known as the "token" method, was primarily designed for client-side applications where the client cannot securely store a client secret. Such applications include single-page apps (SPAs) or other browser-based applications. Instead of receiving an authorization code that needs to be exchanged for an access token, the application gets the access token directly.

Current security guidance (RFC 9700) says the implicit grant SHOULD NOT be used. Prefer the Authorization Code grant with PKCE.

What You Enter in LoadFocus

In a load test, set Authorization Type to OAuth 2.0 and Grant Type to Implicit. The form has these fields:

• Token Name: a label for you. It is not sent to the server.
• Callback URL, Auth URL: the redirect URI registered for your client and the provider's authorization endpoint.
• Client ID, Client Secret, Scope, State, Audience: as issued by or agreed with your provider.

LoadFocus does not open a browser or send a user to the Auth URL, so it cannot complete the redirect step that this grant depends on.

How Does Implicit Grant Type Work?

1. Redirection:

• The client application redirects the user to the OAuth 2.0 authorization server's authorization endpoint. This redirection usually includes query parameters such as client_id, response_type (set to "token" for Implicit Grant), redirect_uri (where the authorization server will redirect after granting/denying access), and scope (indicating the requested level of access).

2. User Authentication:

• The user logs into the authorization server (if not already logged in) and reviews the access request by the client application.

3. Access Token Issuance:

• If the user grants the access, the authorization server redirects them back to the client application via the provided redirect_uri. The redirection URI includes the access token (and its expiration) directly in the fragment part of the URL.

4. Access Protected Resource:

• The client application extracts the access token from the URL fragment and stores it (e.g., in local storage or a session). It then uses this token to make requests to the resource server (API) on behalf of the user.

How to Configure Implicit Grant Type?

1. Register Your Application:

• Start by registering your application with the OAuth 2.0 provider. You'll typically receive a client_id after successful registration.

2. Redirect URI Setup:

• Provide a redirect_uri during registration. The authorization server will redirect users to this URI after they decide on granting or denying access. Ensure this URI is secure (typically using HTTPS) and can handle token extraction from the URL fragment.

3. Initiate OAuth Flow:

• Redirect users to the authorization server's authorization endpoint with the necessary parameters. Use libraries or SDKs suited to your application's language or framework to facilitate this.

4. Extract and Store the Token:

• Once redirected back, extract the access token from the URL fragment. Store the token securely, considering client-side storage options like Web Storage (localStorage or sessionStorage) or cookies. Ensure it's protected from cross-site scripting (XSS) attacks.

5. Use the Token:

• Attach the access token to API requests made to the resource server.

6. Handle Token Expiry:

• The implicit grant never returns a refresh token (RFC 6749 section 4.2.2), so when an access token expires you have to run the OAuth flow again to obtain a new one.

Considerations:

• Security: The Implicit Grant Type is considered less secure than the Authorization Code Grant Type, especially because the access token is exposed in the URL. This could be a risk in environments where URLs can be logged or accessed by third parties.

• No Refresh Token: The authorization server must not issue one for this grant, so the whole flow is repeated when the access token expires.

• Avoid It: Because of these security concerns, the OAuth 2.0 Security Best Current Practice (RFC 9700) says the Implicit Grant SHOULD NOT be used, and recommends the Authorization Code grant with PKCE (Proof Key for Code Exchange) for public clients, like SPAs.

Conclusion:

While the Implicit Grant Type offers a simpler flow for client-side apps, its security concerns have led to recommendations against its use in modern applications. If you're building new applications, especially SPAs, consider using the Authorization Code Grant with PKCE for a more secure approach.