SSO Integration

User Guide: Single Sign-On (SSO) Integration with OIDC and OAuth2

Introduction to Single Sign-On

Single Sign-On (SSO) is a mechanism that allows users to authenticate themselves once and access multiple applications and services without the need to re-enter their credentials. With SSO, users can seamlessly navigate between different systems while maintaining a consistent authentication experience.

Benefits of Single Sign-On

• Simplified user experience: Users only need to remember a single set of credentials to access multiple applications.

• Increased security: SSO reduces the risk of weak or reused passwords and centralizes authentication control.

• Improved productivity: Users can quickly access various applications without repetitive login prompts.

• Streamlined user management: User provisioning and de-provisioning can be managed centrally, saving administrative effort.

Understanding OIDC and OAuth2

• OpenID Connect (OIDC): OIDC is an identity layer built on top of OAuth2, providing user authentication and information about the user.

• OAuth2: OAuth2 is an authorization framework that allows third-party applications to access resources on behalf of the user, without sharing their credentials.

Accessing Datapipes via SSO (e.g., Google, Microsoft)

Datapipes support SSO login to the application using identity federation with OIDC-compliant Identity providers.

Google

In order to user Google as an Identity provider one needs to register Datapipes as a client with Google. Follow https://cloud.google.com/identity-platform/docs/web/google to register Datapipes as a client and provide the following details wherever necessary.

Allowed Javascript Origins

Microsoft (Azure AD)

In order to use Microsoft as an Identity provider one needs to register Datapipes application with Azure AD. Follow https://learn.microsoft.com/en-us/azure/active-directory/saas-apps/openidoauth-tutorial to register Datapipes and provide the following details wherever necessary.

Datapipes by default requires email claim attribute in the user info response, if not provided in response SSO may not work, If different please reach out to Datapipes support team support@datapipes.io with attributes information

Using Datapipes as SSO

Datapipes has the capability to work as an Identity provider for other Applications and can be used to federate the identity of a user as a Datapipes user using OAuth2.

Registering your Application

The following information is needed in order to Register your application as a client in Datapipes to use its identity federation.

• AllowedCorsOrigins[List]: The "AllowedCorsOrigins" setting defines the list of acceptable origins for cross-origin requests. Only requests originating from the specified origins will be allowed to access the server's resources

• GrantTypes[List]: There are several grant types defined in the OAuth 2.0 specification, each serving different use cases and security requirements. Here are some commonly used grant types:

  1. Authorization Code Grant: This grant type is used by web applications that can securely store a client secret. It involves a two-step process where the client first obtains an authorization code from the authorization server and then exchanges that code for an access token.

  2. Implicit Grant: This grant type is primarily used by public clients (e.g., JavaScript applications) running in a user-agent, such as a web browser. The access token is obtained directly from the authorization endpoint without the use of an intermediate authorization code.

  3. Refresh Token Grant: This grant type allows clients to obtain a new access token by presenting a refresh token issued during the initial authorization process. It is used to extend the validity of an access token without requiring the user's explicit authorization.

• RedirectUris[List]: The "AllowedRedirectUris" setting defines the list of URIs that are allowed for this redirection. Only URIs listed in this configuration will be accepted as valid redirect URIs.

• ResponseTypes[List]: The response types are used to indicate what data or tokens the client application wants to receive from the authorization server. The response types can include one or more of the following values:

  1. Code: The authorization code response type is used in the Authorization Code Grant flow. It indicates that the client application wants to receive an authorization code from the authorization server, which can later be exchanged for an access token.

  2. Token: The token response type is used in the Implicit Grant flow. It indicates that the client application wants to receive an access token directly from the authorization endpoint.

  3. ID Token: The ID token response type indicates that the client application wants to receive an ID token, which contains information about the authenticated user.

• Scopes[List]: Scopes in OIDC are represented as strings and are used to define the scope of access for the issued tokens. The scopes typically represent a set of permissions or claims that the client application requires. Datapipes support the following scopes:

  1. openid: This scope indicates that the client application is requesting the user's OpenID, which is an identifier for the authenticated user.

  2. offline_access: This scope indicates that the client application is requesting a refresh token that can be used to obtain new access tokens without user interaction. It allows the client application to have long-lived access to the user's resources.

• TokenEndpointAuthMethod: The TokenEndpointAuthMethod parameter defines how the client application proves its identity to the authorization server during the token exchange process. Datapipes supports the following TokenEndpointAuthMethods:

  1. client_secret_post: This method requires the client application to send its client identifier (client_id) and client secret (client_secret) as part of the POST request body to the token endpoint. The client secret is typically a confidential value known only to the client and the authorization server.

  2. client_secret_basic: This method requires the client application to send its client identifier and client secret as part of the HTTP Basic Authentication header when making the token request. The client identifier and secret are base64-encoded and sent in the "Authorization" header of the request.

  3. private_key_jwt: This method involves the client application using its private key to sign a JSON Web Token (JWT) and include it in the token request. The authorization server can then verify the signature using the corresponding public key.

  4. none: This method indicates that no client authentication is required at the token endpoint. This is typically used in public client applications or in scenarios where the authorization server allows unauthenticated token requests.

Implementing Authentication Flow

• In your application, implement the authentication flow using an OIDC client library or SDK.

• Configure your application to redirect users to the OIDC provider's authorization endpoint to initiate the authentication process.

• Handle the callback URL to receive the authorization code from the OIDC provider.

• Exchange the authorization code for an access token and ID token using the token endpoint.

• Validate and decode the ID token to obtain user information.

• All OIDC-related information is always available from our authorization server as a well-known JSON document can be found at https://{{datapipes_host}}/public/auth/.well-known/openid-configuration

Handling User Authorization

• Determine how to map the user information obtained from the ID token to your application's user model or profile.

• Implement authorization checks based on user roles or permissions.

• Store the user's authentication status and session information securely.

Testing and Troubleshooting

• Perform thorough testing to ensure the SSO integration is functioning as expected.

• Test different scenarios such as new user sign-up, existing user login, and logout flows.

• Monitor and handle potential error cases during the authentication process.

• Troubleshoot any issues by checking error messages, logs, and consulting the OIDC provider's documentation or support resources.

Best Practices for SSO Integration

• Follow security best practices such as using secure communication (HTTPS), protecting client credentials, and implementing proper token handling.

• Implement session management and enforce proper session timeouts to enhance security.

• Regularly review and update your application's integration with the OIDC provider to align with any provider-specific changes or updates.

Conclusion

Implementing SSO using OIDC and OAuth2 can greatly enhance user experience, security, and productivity in your product. By following the integration steps outlined in this guide and adhering to best practices, you can seamlessly integrate SSO into your application and provide a seamless authentication experience for your users.

Remember to consult the documentation and resources provided by your chosen OIDC provider for specific implementation details and guidelines.

Note: This user guide is for informational purposes only and should be adapted and customized to fit your specific product and integration requirements.