Integration With Identity Providers Overview

Authentication is about proving a user's identity. An authorization server can implement this in two main ways. The authorization server can verify a proof itself, such as a password or a digital signature. Or the authorization server can ask an external source to prove the user’s identity and return a result. When the external source performs its own verification of the user's identity we talk about an external identity provider (IdP) or a federated identity provider.

When authentication completes, an external IDP returns a cryptographically protected token and the authorization server verifies it. The authorization server then issues tokens to the client which contain user attributes that the client needs. These user attributes are called claims. Claims can originate from various sources, such as the authorization server’s account data or the external identity provider’s token.

The Curity Identity Server can easily integrate with external identity providers. This section of tutorials show examples of such integrations. Integration with an identity provider depends on whether you are in control of the identity provider (first-party IdP) or whether it is in control of a different organization (third-party IdP). The integration also depends on whether the IdP uses standard protocols like OIDC or SAML, or a bespoke interface.

First-Party IdPs

You may run into limitations with your current identity system as your use cases grow, and want to use the features of the Curity Identity Server. For example, this might improve your abilities to issue the claims you want to tokens, and use advanced features such as token exchange in API to API flows.

Yet in a mature organization it is not usually practical to migrate your entire identity system, and you may be looking for a phased migration. To do so you might deploy the Curity Identity Server in a purely additive manner. Some of your clients and APIs could then be updated to use the Curity Identity Server in the authorization server role, with your existing identity system acting as the identity provider. All other clients and APIs could continue to use your existing identity system. See the following examples for how the Curity Identity Server can integrate with first-party IdPs:

• Integrating with any OpenID Connect-compliant identity provider
• Integrating with any SAML 2.0-compliant identity provider
• Using Microsoft Entra ID as an identity provider

At some point, you might decide to migrate the full identity management to the Curity Identity Server. The following articles can help you with preparing for such a migration:

• Migrating from Keycloak
• Migrating from IdentityServer4
• Migrating from Spring Security

Third-Party IdPs

Another use case is when you want to delegate the authentication process to a third-party provider, for example a social platform. These tutorials show some examples, and you can find more in the sidebar menu for this section and in the authenticators section of the documentation:

• Using "Signin in with Apple" as an identity provider
• Using Google as an identity provider
• Using Facebook as an identity provider
• Using Beyond Identity as an identity provider
• Using BankID as an identity provider

Custom Integrations

Some identity providers use non-standard implementations and have custom requirements. You can integrate with these using the plugin system of the Curity Identity Server. See the following plugins for examples:

• Using Salesforce as an identity provider
• Using LinkedIn as an identity provider
• Using GitHub as an identity provider
• Using Slack as an identity provider

Advanced Use Cases

Sometimes you will need a more advanced use case for your IdP integration. For example, you might operate a multi-tenant setup of the Curity Identity Server and you want every tenant to integrate with their own identity provider. This means that you will integrate with dozens or even hundreds of identity providers, and you might be changing the list frequently.

In such a case it becomes a burden to manage all the configuration settings directly in the Curity Identity Server and its simpler to use a data-driven approach. This is where the Dynamic Authenticator comes in handy. With the Dynamic Authenticator you use an external data source to dynamically get the configuration for an OIDC or SAML-compliant identity provider, making management simpler.

You usually integrate with external identity providers by delegating the authentication process to an IdP, but other options are possible. Credentials Verification with Microsoft Entra ID shows how you can leverage the LDAP interface of your existing identity system to verify a user's credentials directly in the Curity Identity Server.