OAuth2 Implicit Grant with Red Hat SSO v7.1

Pattern / Beni Arnold

In my last post, we looked at how to configure Red Hat SSO v7.1 for OpenID Connect. That post also introduced a web-based OAuth2 + OIDC debugger and the OIDC Authorization Code Authentication Flow. The Red Hat SSO configuration that was created in that post also allows the OAuth2 Implicit Grant to work with the same client.

This brief post demonstrates the OAuth2 Implicit Grant with the OAuth2 + OIDC Debugger available here.

The OAuth2 Implicit Grant is used with applications that require end user authentication, but are not able to keep a client secret secure (ie, a confidential client). This is typically going to be a SPA or javascript application running a browser, but could also be used by other application types that fit this description. Check out this blog post regarding which OAuth2 Grant should be used when.

It is important to understand that Red Hat has implemented OpenID Connect (that runs on top of OAuth2) to provide a comprehensive authentication and SSO solution. In most cases, using the OIDC Authentication Flow is advisable rather than using the OAuth2 Implicit Grant (depicted here). This example is provided for completeness.

  • Configure Red Hat SSO v7.1 as described here.
  • Follow the instructions here to setup the OAuth2 + OIDC Debugger app on your local machine. This is a simple test application that simulates the interaction between a real app and an IdP using the OAuth2 or OIDC protocols.
  • On the Client’s settings screen in the Red Hat SSO admin console, change the Access Type to “public” (the implicit grant doesn’t use a client secret). If a confidential client is used with the OAuth2 Implicit Grant, it will still work with Red Hat SSO v7.1, but the client secret is ignored.



  • Choose Implicit Grant from down down under “Choose Authorization Grant”.


  • Under “Enter Endpoints”, enter the Authorization Endpoint value. For Red Hat SSO v7.1, this will be something like:
https://idp.levvel.io:8443/auth/realms/blog_demo/protocol/openid-connect/auth
  • The Token Endpoint can be left blank for the Implicit Grant.
  • The State and Nonce fields are automatically populated with a GUID value that is sufficiently unique for our purposes during this test.
  • Enter the Client ID you created for your client. If you followed the instructions verbatim in the other blog post, then enter “blog-post-demo-client001”.
  • Enter the Redirect URL for OAuth2 debugger application. The default value for this app is “http://localhost:3000/callback”.
  • Enter the desired scope. We configured a scope (which maps to a role) called “User” earlier.
  • Click the Authorize button.
  • This triggers the the OAuth2 debugger app to make the following call to Red Hat SSO:
GET https://idp.levvel.io:8443/auth/realms/blog_demo/protocol/openid-connect/auth?
state=3e4b0962-d4fd-4e78-91b7-20ad2e768b4b&
nonce=5a419fae-d607-4dba-bf1f-aed9395ffa15&
response_type=token&
client_id=blog-post-demo-client-001&
redirect_uri=http://localhost:3000/callback&
scope=User
  • If the user does not have an authenticated session with Red Hat SSO, then a login prompt is returned:


  • Enter the test user you created previously (“User1” is what the instructions created).
  • Enter the password for this user.
  • Click the “Log in” button.
  • If successful, this results in a 302 redirect to the Redirect URI that was provided (and registered with Red Hat SSO). This URI has a couple of parameters including state and access_token.
  • The state should match the state value that was sent in the original request.
  • The access_token parameter contains the OAuth2 access token.
  • The access_token is extracted from the Redirect URI and displayed in the Results section:


  • Given what we’ve learned about Red Hat SSO, the access token is always going to be a JWT. If the OAuth2 Implicit Grant is going to be used to authenticate the end user to the registered application, then the JWT token needs to validated as outlined in the JWT spec. Ideally, you are using a library that handles this.
  • View the JWT contents by loading the contents of the access_token text box into here.


  • You can see that the user has been successfully authenticated as User1 and the user is a member of the User role.

Per the spec, the Implicit Grant does not provide a refresh token. The details of how to handle session timeouts, logout, and interaction with resources is beyond the scope of this blog post.

Image: Pattern / Beni Arnold