Applications

Single Sign-On (SSO.ID) is a technology that allows a user to log in once and gain access to multiple systems or applications without the need to re-enter their credentials for each one. The term Application in the context of Single Sign-On (SSO.ID) refers to the specific software, service, or system that a user wants to access after they have authenticated with the SSO.ID solution. In SSO.ID implementations, an "Applications" section typically refers to a part of the SSO.ID system where administrators or users can manage and configure the applications that are integrated with the SSO.ID solution. This section is where you set up, configure, and manage the various applications that users can access with SSO.ID

Create an application in SSO.ID

Once you've completed the registration and login process, you'll be able to access the SSO.ID interface. The first step is to set up your application in SSO.ID. To do this, click on the "Create" button to configure your application. When you click on the "Create" button, a dialog box will open with four parameters.

Application Type

Please choose the type of application that best fits your needs from the four options provided in SSO.ID. We have provided brief explanations for your understanding.

Native: A native application is a software program developer built for use on a particular platform for device. The two main mobile OS platforms are Apple’s IOS and Google’s Android.
Single Page Web Applications: A single page web application (SPA) is a type of web application or website that interacts with the user by dynamically rewriting the current web pages rather than loading entire new pages from the server. SPAs load a single HTML page and dynamically update its content as the user interacts with the application.
Regular Web Applications: Also known as multi-page web application (MPA), is traditional type of web application where each interaction or request from the user typically results in the server sending a completely new HTML page to the browser.
Machine to Machine Applications: Machine to Machine (M2M) also known as IoT (Internet of Things) applications involve the communication and interactions between interconnected devices systems, or machines without human intervention.

Protocols in SSO.ID

Single Sign-On (SSO.ID) relies on various protocols to facilitate secure authentication and authorization processes between identity providers and service providers. These protocols ensure that users can access multiple applications with a single set of credentials and that these transactions occur securely.

Select Protocol

SSO.ID offers three protocols. Please select the one that is most suitable for your application.

OAuth Protocol: OAuth (Open Authorization) is an open standard protocol that allows third-party applications to access the resources of a user (such as their data) on a server (often a web service or an API) without exposing the user's credentials (e.g., username and password) to the third-party application. OAuth is commonly used for enabling secure and delegated authorization in various scenarios, such as social media logins, accessing cloud storage, and interacting with web APIs.
Open ID Connect Protocol: Open ID Connect (OIDC) is an identity layer on top of OAuth 2.0, designed to provide a standardized and secure way for user authentication and authorization in modern web and mobile applications. OIDC combines features of OAuth 2.0 with additional identity-related capabilities to enable Single Sign-On (SSO) and identity federation.
SAML Protocol: The Security Assertion Markup Language (SAML) is an XML-based open standard protocol used for securely exchanging authentication and authorization data between parties, particularly between an identity provider (IdP) and a service provider (SP). SAML is commonly used in Single Sign-On (SSO) scenarios and federated identity systems.
Password Based (No Protocol) Password-based Single Sign-On Identity (SSO.ID) without a protocol typically refers to a method of authentication where users utilize a single set of credentials (username and password) to access multiple applications or services within an organization or system, without the need for a specific SSO protocol such as SAML (Security Assertion Markup Language) or OAuth. In this approach, users are required to enter their credentials (typically a username and password) once, and subsequent access to other applications or services is granted without requiring them to re-enter their credentials.

General Configuration with OAuth Protocol

The next step is configuring the settings after successfully creating an application in SSO.ID. Click on the 'Application Config' button. This action will open the general configuration settings dialog on your screen.

GENRAL

Client Secret Key: The Client Secret Key is automatically generated by the SSO.ID system.
Client ID: It is also generated by the system.
Home Page URL: Clients set this URL, and it should be the complete homepage URL of your website.
Redirect URI:In the general settings, one of the most important tasks is to configure your redirect URI. This step is necessary and mandatory, so please set your application's redirect URI with great care. In Single Sign-On Identity (SSO.ID) implementations, specifying multiple redirect URIs for an application can be a common practice to accommodate various scenarios such as different environments (development, testing, production), different client types (web, mobile, desktop), or different callback paths within the same application. Within a single application, it is feasible to incorporate multiple redirect URIs, with the initial URI being established as the default option.
SIGN ON URL: This is an optional URL, it's not mandatory.
Logout URL: You can provide the logout URL for your website or application, it's also optional.

What is Redirect URI

A Redirect URI (Uniform Resource Identifier) is a crucial component in the context of web applications and authentication protocols like OAuth 2.0. It specifies the location to which an authorization server should redirect the user's browser after the user has granted or denied permissions to the requesting application.

OAuth 2.0 Authorization Endpoints

OAuth 2.0 is an open standard for authorization that enables third-party applications to access a user's data without requiring the user's credentials. It was designed to be simple, lightweight, and easy to implement, while providing a secure and scalable way to grant access to protected resources. OAuth 2.0 has become the de facto standard for modern authentication and authorization in web and mobile applications. It is widely used by many popular applications such as Facebook, Google, and Twitter. It provides a simple and secure way to grant access to protected resources, while keeping the user's credentials private.

Components

There are several main components of OAuth 2.0

Resource Owner This is the user who owns the protected resource that the client application wants to access.
Client This is the application that wants to access the protected resource on behalf of the user. It must be registered with the authorization server and have a valid client ID and secret.
Authorization Server This is the server that issues the authorization grants and access tokens. It authenticates the user and approves or denies the client's request to access the user's resources.
Resource Server This is the server that hosts the protected resource that the client application wants to access. It verifies the access token provided by the client and grants or denies access to the resource.
Authorization Grant This is a credential that the client application uses to obtain an access token from the authorization server. There are several types of authorization grants, including authorization code, implicit, client credentials, and resource owner password credentials.
Access Token This is a credential that the client application uses to access the protected resource on behalf of the user. It contains information about the client and the user and is typically short-lived.

Overall, OAuth 2.0 provides a secure and flexible way for applications to access user resources without compromising the user's credentials. By using authorization grants and access tokens, it ensures that only authorized applications can access protected resources, and that the user has control over which applications can access their resources.

Configure OAuth2.0 protocol

Here is how you can configure OAuth2.0 protocol using SSO.ID within just a few simple steps: For detailed request structure and parameters information, please read the endpoints information given below

Create an application on SSO.ID portal.
Add Users and connections to the application.
You can create multiple organizations and assign different connections and users.
Hit the authorize endpoint with client_id you got from portal, redirect_uri where SSO.ID will post the authorization_code, response type = code if you are expecting authorization_code and state(optional
SSO.ID will show a login page where the user must enter credentials.
After successful login SSO.ID will return an authorization_code to your redirect_uri.
Now you need to call the token endpoint with that authorization_code and other parameters in exchange for an access token containing user profile which is customizable depending on grant types and scope you passed in the request parameter.

Oauth Application Endpoints

SSO.ID provides all the features related to the OAuth2.0 and implemented two endpoints which are given below

Authorize Endpoint
Token Endpoint

Authorize Endpoint

On SSO.ID, hitting the authorize endpoint with right request parameters will return a login page where the users can enter their credentials and request for the authorize_code which will be returned to the redirect_uri which was provided in the request parameters. The possible request parameters are client_id, redirect_uri, response_type and state.

GET Authorize

https://app.sso.id/oauth/authorize?client_id={{client_id}}&response_type=code&redirect_uri={{your_app_redirect_uri}}&state={{your_state}}

It will return authorization code to the redirect_uri provided in the request parameter which can be used to get access token.

PARAMS

client_id {{client_id}}

response_type code

redirect_uri {{your_app_redirect_uri}}

State {{your_state}}

Token Endpoint

This endpoint expects compulsory parameters and some optional based on the scope. The main purpose of this endpoint is to validate the authorization_code and return access token containing user information.

Grant Types

SSO.ID supports all the grant types provided by OAuth2.0, which determines the flow of authentication and authorization. Here's an overview of the available grant types.

authorization_code
Implicit
client_credentials
Password

POST authorization_code Grant

https://app.sso.id/oauth2/token

Details

The Authorization Code Grant is the most common grant type and is used for web applications. It involves redirecting the user to the sso.seefar.org login page, where they authenticate and authorize your application. After authorization, SSO.ID returns an authorization code to your application, which is exchanged for an access token.

Body URL encoded

client_id {{client_id}}

client_secret {{client_secret}}

Code {{authorization_code}}

grant_type {{authorization_code}}

redirect_uri {{your_app_redirect_uri}}

Scope {{profile}}

GET Implicit_Grant

The Implicit Grant flow has certain security vulnerabilities and drawbacks, which is why its usage has been discouraged or deprecated in favor of more secure flows like the Authorization Code Grant with PKCE (Proof Key for Code Exchange).

https://app.sso.id/oauth/authorize?client_id={{client_id}}&response_type=type&redirect_uri={{your_app_redirect_uri}}&state={{your_state}}

Details

The Implicit Grant is similar to the Authorization Code Grant but is used for single-page applications (SPAs) where there is no backend server. Instead of exchanging an authorization code for an access token, the access token is returned directly in the URL fragment.

PARAMS

client_id {{client_id}}

client_secret {{client_secret}}

response_type token

redirect_uri {{your_app_redirect_uri}}

Scope {{profile}}

POST Client_credentials Grant

https://app.sso.id/oauth2/token

Details

The Client Credentials Grant is used when your application needs to obtain an access token to access its own resources. This grant type doesn't involve any user authentication and is used for machine-to-machine communication.

Body URL encoded

client_id {{client_id}}

client_secret {{client_secret}}

grant_type client_credentials

redirect_uri {{your_app_redirect_uri}}

POST password Grant

https://app.sso.id/oauth2/token

Resource Owner Password Credentials Grant

The Resource Owner Password Credentials Grant is used when your application wants to authenticate users with a username and password. This grant type requires that your application collect and store user credentials, which can be a security risk.

Body URL encoded

client_id {{client_id}}

client_secret {{client_secret}}

grant_type password

Username {{USER_EMAIL}}

Password {{USER_PASSWORD}}

redirect_uri {{your_app_redirect_uri}}

POST scope

https://app.sso.id/oauth2/token

OpenID The Open ID scope is used for Open ID Connect authentication, which provides user identity information in addition to authentication.

Profile The profile scope is used to obtain the user's basic profile information, such as their name and email address.

Email The email scope is used to obtain the user's email address. To retrieve your email address to the end point of the authorization details according to them. This email id to get all information with the required application. When we select application from application list then we will also retrieve

offline access The offline access scope is used to request a refresh token, which can be used to obtain a new access token without requiring the user to log in again.

custom scopes You can also define custom scopes for your own API, which allow you to grant access to specific resources or functionality within your application End Fragment.

Body URL encoded

client_id {{client_id}}

client_secret {{client_secret}}

Code {{authorization_code}}

grant_type authorization_code

redirect_uri {{your_app_redirect_uri}}

Scope {{profile}}

Logout endpoint

Single Sign-On Identity (SSO.ID) systems typically manage authentication and session management for multiple applications or services. Logging out (or terminating a session) in an SSO.ID environment often involves calling a specific endpoint or method provided by the SSO.ID service. The logout endpoint is in an SSO.ID system may vary depending on the SSO protocol being used (such as OAuth 2.0, OpenID Connect, SAML, etc.) and the implementation or service provider.

GET logout endpoint

https://app.sso.id/oauth/logout?client_id={{client_id}}&redirect_uri={{your_app_redirect_uri}}

Body URL encoded

client_id {{client_id}}

redirect_uri {{your_app_redirect_uri}}

The authorized URL includes a language parameter

we will make the token only a string, however, there is an endpoint to get the users to profile information. https://app.sso.id/oauth2/me?

Headers URL encoded

Authorization: {{bearer Your_token}}

Authorized redirect response

Once the user has logged in, the system will generate a redirect response containing an authorization code, which will be sent to the specified redirect URI. When you encounter a 302-status code in Postman, it typically means that the server is redirecting your request to another URL.

GET authorized URL includes a language parameter

https://app.sso.id/oauth/authorize?client_id={{client_id}}&response_type=code&redirect_uri={{your_app_redirect_uri}}&state={{your_state}}&language=en-US

PARAMS

client_id {{client_id}}

response_type code

redirect_uri {{your_app_redirect_uri}}

Scope {{profile}}

Language {{ISO_language_code}}

Accepted values for language

Language Accepted values

Pashto ps-AF

Farsi fa-IR

Kurdish ku

Urdu ur-PK

Bengali bn-BD

General Configuration with OIDC Protocol

General

Client Secret Key: The Client Secret Key is automatically generated by the SSO.ID system.

Client ID: It is also generated by the system.

Homepage URL: Clients set this URL, and it should be the complete homepage URL of your website.

Redirect URI: In the general settings, one of the most important tasks is to configure your redirect URI. This step is necessary and mandatory, so please set your application's redirect URI with great care. In Single Sign-On Identity (SSO.ID) implementations, specifying multiple redirect URIs for an application can be a common practice to accommodate various scenarios such as different environments (development, testing, production), different client types (web, mobile, desktop), or different callback paths within the same application Within a single application, it is feasible to incorporate multiple redirect URIs, with the initial URI being established as the default option.

SIGN ON URL: This is an optional URL, it's not mandatory.

Logout URL: You can provide the logout URL for your website or application, it's also optional.

BRANDING

In the branding section, you will configure a logo for your created application and select the primary and background colors. These choices will be displayed on your application's interface.

CONNECTIONS

DEFAULT: In the default connection settings, log in to your application using a username and password.

CUSTOM: Go to the custom tab and choose the connections you want to use for logging into your application. You can set up multiple connections for the login process. SSO.ID offers four types of connections, which are:

Google
Facebook
LinkedIn
Azure

Please enable the connections that you want to allow.

ORAGANIZATIONS

In the 'ORGANIZATION' tab, you have the option to choose an organization from the dynamically generated list of organizations to add to your application. This feature is crucial because SSO.ID allows you to select one or more organizations in the application configuration. Organizations are consistently associated with the application. You can easily add or remove any organization with a single click. It's important to note that the same organization cannot be added more than once within the same application.

ALLOWED USERS

In the "Allowed Users" tab, you can grant access to your application to specific users of your choice. Duplicate users are not permitted. You can also assign roles to these allowed users based on their behavior and role requirements. Once you have completed the application configuration settings, click on the "Save" button.

General Configuration with SAML Protocol

A SAML-based application leverages the Security Assertion Markup Language (SAML) protocol for authentication and authorization purposes. SAML is an XML-based framework for exchanging authentication and authorization data between parties, primarily between an identity provider (IdP) and a service provider (SP).

SP CONFIGURATION

Identifier (Entity ID) In Single Sign-On Identity (SSO.ID) implementations, an Identifier or Entity ID serves as a unique identifier for a service provider (SP) or an identity provider (IdP). The Entity ID is a key component of the SAML protocol, widely used for SSO authentication.

Home Page URL The Home Page URL is the destination URL within the SP where the user is redirected after successful authentication. It typically represents the main landing page or dashboard of the application or service.

Reply URL The Reply URL, also known as the Assertion Consumer Service (ACS) URL, is the endpoint within the SP where the Identity Provider (IdP) sends SAML assertions after successful authentication.

Sign On URL It's the URL to which the Identity Provider (IdP) redirects users for authentication as part of the SAML Single Sign-On (SSO) process.

SAML Assertion Response Method In the context of Single Sign-On Identity (SSO.ID) using the Security Assertion Markup Language (SAML) protocol, there are typically two types of SAML assertion response methods.

POST Binding In the POST binding, the SAML assertion response is sent as a form POST from the Identity Provider (IdP) to the Service Provider (SP). This method is commonly used for browser-based SSO flows where the IdP and SP can communicate directly with each other via HTTP POST requests.

Redirect Binding In the Redirect binding, the SAML assertion response is encoded as a URL parameter and sent as part of a redirect response from the IdP to the SP. Redirect binding is lightweight and can work in environments where POST requests might be restricted or not feasible.

Name Format The Name ID Format specifies how the subject of the SAML assertion, which typically represents the user, is structured and presented. It's crucial for interoperability between different SAML implementations, ensuring that both the IdP and SP understand how to interpret and process the user's identity

Unspecified This format indicates that the IdP doesn't specify a particular format for the Name ID. It's the default format when no specific format is requested.
Email The user's email address is used as the Name ID. This format is often used when the user's email serves as a unique identifier.
Transient A transient identifier generated by the IdP is used as the Name ID. This identifier is unique for each session and is not persistent across sessions.
Persistent A persistent identifier assigned by the IdP is used as the Name ID. This identifier remains consistent for the same user across different sessions.

Relay state The Relay State parameter allows the Service Provider (SP) to maintain state information and control the user's post-authentication behavior.

ATTRIBUTES & CLAIMS

In SAML (Security Assertion Markup Language) configuration as an Identity Provider (IDP), "Attributes" and "Claims" play significant roles in defining what information about the user should be included in the SAML assertion sent to the Service Provider (SP).

Attributes: Attributes are pieces of information about the user that the IDP can provide to the SP. These can include things like the user's name, email address, role, group membership, and any other relevant information.

Claims: In the context of SAML, claims are assertions made by the IDP about the user. These claims are statements about the user's identity or attributes. Claims can include information such as the user's identity, authentication method, and any other relevant information.

SSO IDP METADAT

In SAML (Security Assertion Markup Language), the SSO.ID (Single Sign-On Identity) Identity Provider (IDP) metadata contains information about the identity provider that can be used by service providers (SP) to establish trust and configure their systems accordingly. The SSO.ID IDP metadata typically includes.

Entity ID
SSO Endpoint
Signing Certificate
Encryption Certificate
Supported SAML Bindings

BRANDING

In the branding section, you will configure a logo for your created application and select the primary and background colors. These choices will be displayed on your application's interface.

CONNECTIONS

Default In the default connection settings, log in to your application using a username and password. Custom Go to the custom tab and choose the connections you want to use for logging into your application. You can set up multiple connections for the login process. SSO.ID offers four types of connections, which are.

Google
Facebook
LinkedIn
Azure

Please enable the connections that you want to allow.

ORAGANIZATIONS

ALLOWED USERS

In the "Allowed Users" tab, you can grant access to your application to specific users of your choice. Duplicate users are not permitted. You can also assign roles to these allowed users based on their behavior and role requirements. Once you have completed the SAML application configuration settings, click on the "Save" button.

MULTIFACTORS

Multi-factor authentication (MFA), also known as two-factor authentication (2FA), is a security process in which a user is required to provide two or more separate forms of identification factors to verify their identity during the login or authentication process. The goal of MFA is to add an extra layer of security beyond just a username and password, as these can often be compromised. SSO.ID offers two authentication methods for its clients when it comes to multi-factor authentication.

Email
Phone Message

You can easily enable either one or two authentication methods for both your application and your organization (tenant). We provide a comprehensive guide on how to enable email addresses or phone numbers for authentication in your application and tenant.