OpenID Connect Standards

architect

5 min

On this page

The Curity Identity Server enables the use of a wide range of identity-related standards. It supports a growing list of OAuth, OpenID Connect, SCIM and related protocols from standard bodies such as IETF, OpenID Foundation and OASIS.

OpenID Connect introduces a large number of capabilities that are used for many scenarios and across many industries. The OpenID-related standards that the Curity Identity Server supports are listed below:

Standards Area	Summary of Behavior
Core	The core authentication behavior built on top of OAuth 2.0, along with the use of ID tokens and claims to communicate information about the end-user in a digitally verifiable way. In addition to required behavior, optional features include Pairwise Pseudonymous Identifiers (PPID), the Claims Parameter and Self-Issued OpenID Provider (SIOP) support.
Discovery	The interoperability mechanism for relying parties to dynamically discover the end-user's OpenID Provider, understand its supported features, and obtain information needed to interact with it. Issuer Discovery is also supported, so that the location of the Curity OpenID Provider can be determined via WebFinger.
Basic Client	The part of the core specification to enable web based relying parties to use the Authorization Code Flow. This includes an OpenID Connect authenticator that can be used to manage user sign in via external OpenID providers.
Implicit Client	The OAuth implicit grant enables a relying party to authenticate and receive tokens using only the front channel. The OpenID Connect adds ID tokens to the flow, allowing relying parties to receive proof of the authentication event via a digitally verifiable JSON Web Token (JWT).
Hybrid Client	The ability to authenticate and receive tokens on both the front channel and back channel, with an additional ID token c_hash claim that enables the relying party to perform strong security checks before using tokens.
Dynamic Client Registration (DCR)	The interoperability mechanisms that enable an approved relying party to securely and dynamically register as an OAuth client, with no manual setup steps. Multiple forms of authentication are supported in order to get a DCR access token with a `dcr` scope so that registration can be done securely. Pre-processing before issuing the DCR access token is customizable via script and can be used to make additional region-specific checks if needed, in regulated industries such as banking.
Dynamic Client Registration Management (DCRM)	The ability to use a registration_access_token and registration_client_uri as defined in OpenID Connect Registration, as well as the support for a Client Configuration Endpoint. In addition the entire IETF DCRM Specification is implemented.
Form Post Response Mode	A mechanism to return sensitive OAuth fields to the relying party via an HTML form that is automatically submitted. This ensures that the authorization code is excluded from the browser history and server logs.
3rd-party Initiated Login	An `initiate_login_uri` endpoint can be registered against a relying party, so that a third party can use this endpoint to perform an IDP initiated login. This mechanism also supports deep links, where a `target_link_uri` is verified by the relying party before allowing the request.
Single Logout	The full suite of logout-related specifications, with RP-initiated Logout, Session Management, Front-channel Logout and Back-channel Logout.
CIBA	The ability to initiate authentication on one device and then complete it on another. This enables scenarios such as a call center operative asking a remote user to authenticate, then using the end-user's claims in the call center app.
CIBA FAPI	A financial-grade profile providing recommendations when using CIBA decoupled flows to protect high-worth data. This mandates the use of confidential clients, signed authentication requests and additional claims, which may include those related to geolocation.
FAPI Security Profile 1.0 - Part 1	The Financial Grade API (FAPI) baseline profile is a set of requirements and best practices when protecting data. Key features include use of strong authentication by confidential clients, via Mutual TLS or Client / User Assertions, and use of Proof Key for Code Exchange (PKCE) by public clients.
FAPI Security Profile 1.0 - Part 2	The Financial Grade API (FAPI) advanced profile requires further development effort to protect high-worth data, once the baseline profile has been implemented. This includes using the request or request_uri parameters with the Authorization Code Flow, accepting only JWTs with the strongest encryption algorithms, and using only Sender Constrained Access Tokens.
FAPI 2.0 Security Profile	A high-security profile that provides requirements based on an attacker model for protecting APIs that expose high-value data. Though it was originally designed for financial applications, the FAPI 2.0 Security Profile is suitable for any scenario with high-security demands.
Health Relationship Trust Profile (HEART)	A set of requirements that increases baseline security and improves operability in a manner specifically applicable to (but not limited to) the healthcare domain. Advanced options include the use of JWT Assertions for client authentication and accepting only Proof of Possession access tokens in APIs.

The following links provide further background about OpenID certification:

Standards & Conformance

Complete list of supported standards

Future Standards

Curity is always actively working on adding support for newer parts of the OpenID Connect framework. If you're missing a spec or have questions contact us for more details.