Authorization with SSO Providers

This guide will walk you through the key differences and options available for managing authorization in your applications, when using SSO with an external OIDC or SAML IdP.

All Tenants that are created in Descope can have their own Roles and Permissions defined.

SAML has a lot more features in general when compared to OIDC, including

SAML

SAML is a widely used standard for SSO, particularly in enterprise environments. It allows users to authenticate through a central identity provider (IdP) and then access various services without needing to log in again. When using SAML with Descope, you can leverage the following features for authorization:

1. Group-Based Authorization:
   • SAML allows you to define user groups within your IdP.
   • These groups can be mapped directly to specific roles within Descope.
   • When a user logs in via SAML, their group membership is sent in the SAML assertion.
   • Descope then maps these groups to roles within your application, allowing you to control access based on the user's group.

2. Role Mapping:
   • You can create roles within Descope that correspond to the groups defined in your SAML IdP.
   • This mapping is particularly useful for enterprises where access control is managed centrally, and you want to reflect those controls in your Descope-integrated applications.

Example: Group Mapping Configuration

Let’s say you have three departments in your Azure AD, each with specific groups:

In this setup:

• A user who belongs to the Engineering group in Azure AD will be assigned the Developer Team role in Descope.
• If this user logs in through SAML, their group information is passed in the assertion, and Descope will apply the mapped role automatically.

OIDC (OpenID Connect)

OIDC is another popular protocol for SSO, especially in modern web and mobile applications. It builds on top of OAuth 2.0 and provides a standardized way to authenticate users and obtain their identity information. The OIDC standard does not define how group mapping should be managed, and thus is not supported like it is with SAML.

However, with Descope there are ways that authorization can be managed when using OIDC providers. The OIDC-specific strategies are mentioned here:

1. Attribute Mapping:

   • OIDC providers allow you to include various attributes about the user, such as their roles, permissions, or group memberships, as a claim in the id_token returned to SPs like Descope.
   • In Descope, you can map these attributes to custom attributes for users defined in the Descope Console.
   • This allows you to associate authorization information with specific Descope managed users, which can be used by your application to enforce access control.

2. Custom Claims and JWT Templates:

   • Descope allows you to create custom claims in the JWTs issued to your users.
   • By mapping attributes from your OIDC provider, you can embed specific authorization details (like roles or permissions) into the token.
   • This approach is flexible and allows you to tailor the authorization model to fit your application’s needs.

Summary

• For SAML providers: Use group-based authorization and role mapping to control access within Descope.
• For OIDC providers: Leverage attribute mapping and custom claims to include authorization details in the JWTs issued by Descope.