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.
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.
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
Acquire access token
Request an access token post successful authorization.
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.
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:
curl -G https://eu-test.oppwa.com/sso/v2/authorize \ -d "client_id=8a829418504762810150482b9432129d" \ -d "redirect_uri=https://www.payunity.com/tutorials/openid" \ -d "scope=openid" \ -d "response_type=code" \ -d "login_hint=8ac7a4c79394bdc801939736f17e063d" \ -d "state=dcc05834-018b-451f-bda0-ef54b30eef46"
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)) .
|
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:
curl https://eu-test.oppwa.com/sso/v2/token \ -d "code=" \ -d "redirect_uri=https://www.payunity.com/tutorials/openid" \ -d "scope=openid" \ -d "grant_type=authorization_code" \ -H "Authorization: Basic OGE4Mjk0MTg1MDQ3NjI4MTAxNTA0ODJiOTQzMjEyOWQ6cDBLdVNFU0pmLUpBWnl0NXN1UVY="
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:
|
attached_to | ARRAY | JSON array of objects, each representing an attachment level with:
|
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:
curl -G https://eu-test.oppwa.com/sso/v2/userinfo \ \ -H "Authorization: Bearer <access-token>"