How To: Test OAuth / OpenID Connect Flows

Version Affected: All

 

Overview

This article gives the exact steps to make a test call to the SecureAuth Identity Provider (IdP) for each OAuth 2.0 / OpenID Connect (OIDC) flow.
The examples below use a browser, Postman, or a combination of both - the same calls can be made using any other HTTP client or tool.

For an explanation of each flow, its communication pattern, and when you should or should not use it, see OAuth 2.0 / OpenID Connect Flows: Overview.

This article also covers several related endpoints you'll commonly need once you have tokens: creating and using a refresh token, revoking and introspecting a token, retrieving user info, and ending the session.

In this article

• Test the Client Credentials flow
• Test the Implicit flow
• Test the Hybrid flow
• Test the Authorization Code flow
• Test the Resource Owner Password flow
• Create a Refresh Token
• Test the Refresh Token grant
• Test the Revocation Endpoint
• Test the Introspection Endpoint
• Test the UserInfo Endpoint
• Test the EndSession Endpoint

Test the Client Credentials flow

1. In the SecureAuth Admin Console, open the realm's Post Authentication tab and add a custom scope. This example uses a scope named client_creds_scope.
2. Send a POST request to the token endpoint with grant_type=client_credentials, your client_id, client_secret, and the custom scope you created in step 1. No other parameters are required.

Screenshot: the Post Authentication tab with a custom scope named "client_creds_scope" added to the realm configuration.

Screenshot: an example POST request to the token endpoint, showing grant_type set to client_credentials along with the client_id, client_secret, and scope parameters.

Test the Implicit flow

Point the browser to a URL in this format, replacing the placeholders as described below:

https://<your-idp-fqdn>/<your-realm>/?response_type=<see options below>&client_id=<your-client-id>&redirect_uri=<your-redirect-uri>&scope=<your-scope>&state=State&nonce=<your-nonce>

• <your-idp-fqdn> — the fully qualified domain name of your SecureAuth server.
• <your-realm> — your OAuth realm name.
• client_id — your application's Client ID.
• redirect_uri — your application's registered redirect URI.
• scope — the scope(s) to request. Include openid if you need an ID token (see response_type options below). Add more scopes to return more claims in the ID token.
• nonce — required for every request; use a unique value each time.

Set response_type to one of the following, depending on what you need returned:

• token — returns an access token only.
• id_token — returns an ID token only.
• id_token+token — returns both an access token and an ID token.

Example - 

https://secureauth.domain.com/secureauth33/secureauth.aspx?response_type=id_token&scope=openid&client_id=53cbac632d7753afbd5732f1bec6ff7d&redirect_uri=https://www.jwt.ms&nonce=e95618d0b1cdfae2fde823f133f05bd7

The URL in the Address bar will include the ID Token (if response type included 'id_token' and the scope was 'openid') or the Access and ID Token (if response type included 'id_token token' and the scope was 'openid profile email')

Test the Hybrid flow

Point the browser to a URL in this format, replacing the placeholders as described below:

https://<your-idp-fqdn>/<your-realm>/?response_type=<see options below>&client_id=<your-client-id>&redirect_uri=<your-redirect-uri>&scope=openid+profile&state=State&nonce=<your-nonce>

• <your-idp-fqdn> — the fully qualified domain name of your SecureAuth server.
• <your-realm> — your OAuth realm name.
• client_id — your OIDC application's Client ID.
• redirect_uri — your application's registered redirect URI - as specified in the IdP OIDC Client.
• scope — must include openid; add more scopes as needed.
• nonce — required for every request; use a unique value each time.

Set response_type to one of the following valid combinations. The values must be written in the exact order shown — writing them in a different order causes an error:

• code id_token — returns an authorization code and an ID token.
• code id_token token — returns an authorization code, an ID token, and an access token.
• code token — returns an authorization code and an access token.

Example - 

https://secureauth.domain.com/secureauth33/secureauth.aspx?response_type=id_token&scope=openid&client_id=53cbac632d7753afbd5732f1bec6ff7d&redirect_uri=https://www.jwt.ms&nonce=e95618d0b1cdfae2fde823f133f05bd7

The URL in the Address bar will include the ID Token (if response type included 'id_token' and the scope was 'openid') or the Access and ID Token (if response type included 'id_token token' and the scope was 'openid profile email')

If you use the code afterward, send it to the token endpoint the same way as described in Test the Authorization Code flow below.

Test the Authorization Code flow

1. Get an authorization code by pointing the browser to a URL in this format, replacing the placeholders as described in the Hybrid flow above: 

   https://<your-idp-fqdn>/<your-realm>/secureauth.aspx?response_type=code&client_id=<your-client-id>&redirect_uri=<your-redirect-uri>&scope=openid+offline_access&state=<your-state>

   Example

   https://secureauth.domain.com/secureauth30/secureauth.aspx?response_type=code&client_id=fa7069b5476837b0088d2dbee4c6b2&redirect_uri=https://www.jwt.ms&scope=openid+offline_access&state=5676a2eb84fc0f40ee3665ddd954e319

   The IdP redirects the browser back to your redirect_uri with the authorization code included as a query parameter.
    

2. Using Postman (or similar) - Send the authorization code to the token endpoint to exchange it for tokens:
   • POST to https://<your-idp-fqdn>/<your-realm>/oidctoken.aspx
   • Content type: application/x-www-form-urlencoded
   • Body parameters:
     • grant_type — authorization_code
     • code — the authorization code retrieved in step 1
     • client_id — your application's Client ID
     • client_secret — your application's Client Secret
     • scope — openid and any other scopes you need
     • redirect_uri — the same redirect URI used in step 1

Screenshot: an example POST request to the token endpoint, exchanging an authorization code for tokens using grant_type=authorization_code.

If your OIDC client uses PKCE (Proof Key for Code Exchange) instead of a client secret, the token exchange in step 2 differs slightly: send code_verifier in place of client_secret. Confirm PKCE is enabled for the client first: on the Post Authentication tab, under OpenID Connect/OAuth 2.0 - Clients, open the client and make sure Use with PKCE Protocol is checked next to the Authorization Code entry under Allowed Flows.

Test the Resource Owner Password flow

1. Send a POST request to the token endpoint:
   • POST to https://<your-idp-fqdn>/<your-realm>/oidctoken.aspx
   • Content type: application/x-www-form-urlencoded
   • Body parameters:
     • grant_type — password
     • scope — openid
     • username — the end user's username
     • password — the end user's password
     • client_id — your application's Client ID
     • client_secret — your application's Client Secret

Screenshot: an example POST request to the token endpoint using grant_type=password with a username and password.

Create a Refresh Token

Before you can test the Refresh Token grant below, the realm and request must be set up to have SecureAuth issue one.

1. On the realm's Post Authentication tab, open the OpenID Connect/OAuth 2.0 client and set Refresh Token to True.
2. Request the offline_access scope, along with at least one standard OpenID scope such as openid, profile, or email. Requesting a standard OpenID scope is what makes SecureAuth treat the call as OpenID Connect (OIDC) rather than plain OAuth 2.0 — offline_access only triggers a refresh token under OIDC rules.
   
   
    
3. Enable Enable User Consent Storage and set a Consent Storage Attribute (for example, one of the Aux ID fields) on the realm's OpenID Connect/OAuth 2.0 Settings.
   
   
    
4. On the realm's Data tab, map the same Consent Storage Attribute to an unused Active Directory attribute, and make it writable.

If you request only a custom scope — with none of the standard OpenID scopes above — SecureAuth treats the call as plain OAuth 2.0 rather than OIDC. In that case, whether a refresh token is issued is controlled solely by the client's Refresh Token setting, and the offline_access requirement above doesn't apply.

Test the Refresh Token grant

Once you have a refresh token from a previous flow — for example, the Authorization Code flow with the offline_access scope — use it to get a new access token without the user re-authenticating.

1. POST to https://<your-idp-fqdn>/<your-realm>/oidctoken.aspx
2. Content type: application/x-www-form-urlencoded
3. Body parameters:
   • grant_type — refresh_token
   • client_id — your application's Client ID
   • client_secret — your application's Client Secret
   • redirect_uri — the same redirect URI registered for the client
   • refresh_token — the refresh token you received from the previous flow

Screenshot: an example POST request to the token endpoint exchanging a refresh token for a new access token, ID token, and refresh token using grant_type=refresh_token.

Test the Revocation Endpoint

Use the Revocation endpoint to invalidate a token before it naturally expires. Revocation works best paired with the Introspection endpoint below, so you can confirm a token was actually revoked. If you haven't already, enable consent storage as described in Create a Refresh Token above.

To revoke a token:

1. POST to https://<your-idp-fqdn>/<your-realm>/oauthrevocate.aspx
2. Content type: application/x-www-form-urlencoded
3. Body parameters:
   • client_id — your application's Client ID
   • client_secret — your application's Client Secret
   • token — the access or refresh token you want to revoke

Screenshot: an example POST request to the Revocation endpoint with client_id, client_secret, and the token to revoke.

To confirm the token was revoked, introspect it — see Test the Introspection Endpoint below. After revocation, the introspection response returns "active": false.

Test the Introspection Endpoint

Use the Introspection endpoint to check whether a token is still active — useful on its own, and to confirm a token was actually revoked (see Test the Revocation Endpoint above).

1. Ensure Consent Storage is set to True on the OIDC realm's Post Authentication page.
   
   
    
2. Ensure the OIDC Consent Storage Profile Property is mapped to an acceptable Datastore attribute and set to writable.
   
   
    
3. Ensure the Introspection Endpoint is enabled on the OIDC Client, on the same Client Details page where Allowed Flows are configured.
   
   
    
4. POST to https://<your-idp-fqdn>/<your-realm>/oauthintrospect.aspx with:
   • client_id — your application's Client ID
   • client_secret — your application's Client Secret
   • token — the token you're introspecting

Screenshot: an example POST request to the Introspection endpoint, with the response body showing active: true along with the token's client_id, username, audience, issuer, expiration, and scope.

Test the UserInfo Endpoint

The UserInfo endpoint returns the authenticated user's identity information for a given access token.

1. POST to https://<your-idp-fqdn>/<your-realm>/oidcuserinfo.aspx
2. Content type: application/x-www-form-urlencoded
3. Body parameters:
   • access_token — the access token you received from any flow above

Screenshot: an example POST request to the UserInfo endpoint with an access_token, returning a JSON response with the user's identity claims.

Test the EndSession Endpoint

Use the EndSession endpoint to clear SecureAuth's session cookies when a user logs out of your application. This is especially useful if a realm has multiple OIDC clients, since it lets the next login start with a clean query string.

When the user logs out of your app, redirect them to a URL in this format:

https://<your-idp-fqdn>/<your-realm>/oidcendsession.aspx?client_id=<your-client-id>&post_logout_redirect_uri=<your-redirect-uri>

• <your-idp-fqdn> — the fully qualified domain name of your SecureAuth server.
• <your-realm> — your OAuth realm name.
• client_id — your application's Client ID.
• post_logout_redirect_uri — must be listed in the client's Redirect URIs on the Post Authentication tab.

Screenshot: the Client Redirect URIs section of the Post Authentication tab, where the post_logout_redirect_uri value must be registered.

Special Considerations

• When testing the Resource Owner Password flow, only send the request over HTTPS, since the username and password are sent in the POST body.
• On SecureAuth IdP 20.06, Authorization Code with PKCE could unexpectedly require client_secret even with PKCE enabled, due to a defect fixed in HF8 (with further PKCE improvements in HF12 and HF14). If you hit this on that version, install the latest available hotfix.

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.