Single Sign On Integration Guide

Last updated:April 07, 2025

Imagine a world where one set of credentials gives you access to multiple applications. That’s the convenience Single Sign-On (SSO) brings. It simplifies user experience, reduces password fatigue, and enhances security.

What makes OAuth OpenID Connect special?
OAuth OpenID Connect is the engine that powers SSO. It’s an authentication standard built on OAuth 2.0. Unlike SAML, which uses XML, OAuth OpenID Connect uses JSON. This makes it lightweight and perfect for the web. It verifies user identity and gathers basic profile information in a secure and efficient manner.
Why are SSO and OAuth OpenID Connect the perfect pair?
When you log into one application using SSO with OAuth OpenID Connect, you’re authenticated across all connected applications. It’s seamless, efficient, and the future of authentication.

Use cases

User login

Authenticate swiftly and securely with your trusted identity provider. Experience a seamless login process, bypassing the need to remember another set of credentials. Enjoy the enhanced security provided by your identity provider’s robust authentication measures. This is the convenience and security of Single Sign-On.


How it works

User-Browser Interaction

Initiate authorization

Redirect the user to the identity provider's page.

Application-Server Interaction

Acquire access token

Request an access token post successful authorization.

Application-Server Interaction

Retrieve user information

Use the access token to fetch user information and decide to grant the user access.


1. Initiate authorization

This step occurs in the user’s browser.

  • Initiate Authorization: Your application redirects the user’s browser to the identity provider’s authorization endpoint (/v2/authorize).
  • User Login: The user enters their credentials and logs in on the identity provider’s page.
  • Two-Factor Authentication (2FA): If enabled, the user completes the second factor (e.g., entering a code sent to their mobile device).
  • Return to Application: Post successful login and 2FA verification, the user’s browser is redirected back to your application using the predefined redirect URL.
When integrating with our SSO application based on OpenID Connect, it is crucial to obtain explicit end-user consent before including Personally Identifiable Information (PII) such as name and preferred_username in the /sso/v2/userinfo response. This consent is automatically integrated during the authorization flow when the scope=openid profile is requested. External applications should ensure they comply with this process to maintain user trust and data privacy.
Request Parameter Mandatory Format Comment
client_id Yes AN OAuth client ID, an attribute of an OAUTH_APP user on Open Payment Platform.
redirect_uri Yes AN URL to redirect user after successful authorization. Must be URL-encoded.
scope Yes AN Scope for accessing data. Use scope=openid for OpenID Connect, or scope=openid profile to also request additional user profile information.
response_type Yes AN Type of OAuth2 workflow to execute. Use response_type=code for the authorization code flow.
login_hint No AN Optional entity identifier to retrieve custom UI styles for the login prompt.
state No AN Optional parameter to prevent CSRF. The same value sent by the redirect will be returned to the client application.

Sample request:

2. Acquire access token

This step is handled by your application’s server.

  • Acquire Access Token: Your application makes a request to the identity provider’s token endpoint (/v2/token) and receives an access token.
Request Header Mandatory Format Comment
Authorization Yes AN Follows HTTP Basic authentication. Formatted as "Basic " + base64.encode(url_encode(client_id) + ‘:’ + url_encode(client_secret)).
  • client_id: Unique OAuth contact identifier for your application, provided by the identity provider.
  • client_secret: Confidential key for your application, provided by the identity provider.
Request Parameter Mandatory Format Comment
code Yes AN One-time use code passed by authentication.
redirect_uri Yes AN Redirect URL from the first redirect.
scope Yes AN Token scope. Use scope=openid for OpenID Connect, or scope=openid profile to also request additional user profile information.
grant_type Yes AN Grant type for the token request. Currently accepts authorization_code only.
Response Parameter Format Comment
access_token AN256 This is the key that permits an application to make further requests on behalf of a user.
refresh_token AN256 A token used to obtain a new access token when the current access token expires. It allows the client to maintain access without requiring the user to re-authenticate.
scope AN Defines the scope of the access. At present, it’s set to scope=openid for OpenID Connect, or scope=openid profile for additional user profile information.
id_token AN256 A JSON Web Token (JWT) that contains claims about the authenticated user, such as their identity and email. This token can be parsed to obtain user information directly, reducing the need for additional requests to the /userinfo endpoint.
token_type AN Specifies the OAuth2 token type. Currently, it’s Bearer.
expires_in N Specifies the lifespan of the access token in seconds.

Sample request:

3. Retrieve user information

This step is also handled by your application’s server.

  • Retrieve User Information: Your application uses the access token to query the identity provider’s user information endpoint (/v2/userinfo).
  • User Login Confirmation: Based on the received information and your application’s rules, decide whether to grant the user access.
Request Header Mandatory Format Comment
Authorization Yes AN256 Contains the bearer token for authorization. It’s formatted as "Bearer " + access_token.
Response Parameter Format Comment
sub AN32 Unique key identifying the subject. Represents the contact identifier.
role AN256 User’s role, which can be one of several predefined roles such as:
  • Account Access
  • Accounting Global
  • Administrator
  • Analysis
  • Callcentre
  • Callcentre Restricted
  • Operator
attached_to ARRAY JSON array of objects, each representing an attachment level with:
  • entityId: Entity ID where the contact is attached.
  • entityType: Attachment level (e.g. PSP, DIVISION, MERCHANT or CHANNEL)
  • path: Names of the entities separated by "/" (e.g. /<pspName>/<divisionName/<merchantName>/<channelName>)
  • pathOfIds: Entity identifiers separated by "/" (e.g. /<entityId1>/<entityId2>/<entityId3>/<entityId4>)
  • Deprecated level: Attachment level (e.g. PSP, DIVISION, MERCHANT or CHANNEL)
name AN35 Contact’s name. Provided only when scope=openid profile.
preferred_username AN256 Contact’s username (email address). Provided only when scope=openid profile.

Sample request:

Session Tracker

Experience the power of real-time session tracking in Single Sign-On (SSO). Our session tracker keeps you informed about the user’s active status in the Authentication Manager and any logout actions from connected applications. Upon logout, your application receives an instant alert, enabling swift response. Post-action, your application is ready to initiate a new Login Workflow, ensuring a smooth transition for potential user re-login. Discover enhanced control and fluid user management with our session tracker in SSO.

Here’s the swift workflow:
  • User logs into your application via the Login Workflow.
  • User navigates to a different application, like the Open Payment Platform.
  • User logs out, activating the Logout workflow on the visited application.
  • User accesses an internal page in your application. The Session Tracker JavaScript Snippet promptly alerts your application about the session change.
  • Your application swiftly terminates the local user session and readies a new Login Workflow.

How it works

Responding to logout events

Listen to logout events.

Verifying user login status (individual check)

Perform individual checks to see if the user has remotely logged out.

Verifying user login status (polling)

Continually verifies at set intervals if the user has logged out.


1. Responding to logout events

Your application can receive notifications about changes in the user’s remote session (on the Authentication Manager) by embedding a JavaScript Snippet on each page of your application. This allows your application to take action, such as terminating the local user session and initiating a new Login Workflow.
Please add the following JavaScript code to each page of your application that needs to respond to remote logout events:

Sample:

<script type="text/javascript">
(function(w, d, o, u, r, a, m)  {
	w[r] = w[r] ||
		function() {
			(w[r].q = w[r].q || []).push(arguments);
	};
	a = d.createElement(o),
	m = d.getElementsByTagName(o)[0];
	a.async = 1;
	a.src = u;
	m.parentNode.insertBefore(a, m);
})(window, document, 'script', 'https://eu-test.oppwa.com/sso/sessionTracker/oasm.js', '_OASM');
 
//put your client id instead of {your_client_id}
_OASM('client_id', '{your_client_id}');
 
//callback for whenever the session status is different than expected
_OASM('on_change', function(){
	//remove user session locally
	//start a new Login Workflow
});
</script>
			

2. Verifying user login status (individual check)

After integrating the above script into your page, your application can perform individual checks to see if the user has remotely logged out. If the remote login status of the user is not as expected (‘logged_in’), your application will be notified via the function defined by _OASM('on_change').

Sample:

_OASM('check', 'logged_in');

3. Verifying user login status (polling)

Your application can also set up a polling mechanism that continually verifies at set intervals if the user has logged out.

Sample:

// Set the interval (in milliseconds) at which your application should verify if the user has logged out.
_OASM('poll', {state:'logged_in', interval: 10000});
			

User logout

Authenticate swiftly and securely with your trusted identity provider. Experience a seamless login process, bypassing the need to remember another set of credentials. Enjoy the enhanced security provided by your identity provider’s robust authentication measures. This is the convenience and security of Single Sign-On.


How it works

Terminate session

Redirect the user to the identity provider's page.


1. Terminate session

Redirect the user to the identity provider’s page to initiate the authorization process.

Sample request:


See also