Standards and Conformance
Conforming to Standards Protects Your Users
Industry standards are designed, developed and vetted by experts and help ensure a high baseline of security.
Industry Standards to Future-Proof Your Investment
In today’s fast-paced and competitive digital world, organizations cannot afford to invest time and money in technology that doesn’t integrate easily with other solutions, creates vendor lock-in, makes it challenging to recruit new talent, or is proven not to be reliable. The Curity identity Server is built on established industry standards that are proven and tested, supporting the security of your organization over the long-term.
Industry Certifications
Curity Identity Server has been certified to conform to the OpenID Connect and Mobile Connect standards. In particular, the Curity product has been self-certified to comply with the basic, implicit, hybrid and configuration protocols of OpenID Connect. Support for Mobile Connect v. 1.1 has been certified by GSMA.
A Growing List of Supported Standards
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. In addition to integration standards, a large number of user authentication standards such as Kerberos, TOTP and SAML, are also supported.
OAuth
OAuth is an open standard, which provides clients secure delegated access to server resources on behalf of a resource owner. It can be complex though and the Curity Identity Server helps you manage these complexities, making it easier to use, customize and deploy.
| RFC or Spec | Name | Purpose of Standard |
|---|---|---|
RFC9101 | JWT Secured Authorization Request (JAR) | This specification ensures that a man-in-the middle cannot change authorization requests; it can be encrypted as well to ensure that such intermediaries cannot view data in the request. This is important when the request contains Personally Identifiable Information (PII). |
RFC9126 | Pushed Authorization Requests (PAR) | This specification ensures that only authenticated clients can start an authorization flow. It is used together with JAR to provide a method to save authorization data at the authorization server, relay a reference to that data via a browser, and complete the user authorization without negatively impacting the Quality of Service (QoS) of the authorization server. |
RFC6749 | The OAuth 2.0 Authorization Framework | The base specification for OAuth 2.0. This encapsulates the four basic flows of OAuth: The Code Flow, The Implicit Flow, the Client Credentials Flow and the Resource Owner Password Credentials Flow |
RFC7662 | OAuth 2.0 Token Introspection | This specification adds the capbility of being able to introspect tokens. When using opqaue tokens this is needed so that the API or the Gateway can validate the token and retrieve its contents |
RFC7009 | OAuth 2.0 Token Revocation | Token revocation allows the client to revoke issued tokens by calling the revoke endpoint on the OAuth Server |
RFC8628 | OAuth 2.0 Device Authorization Grant | This specification adds a new grant type for retrieving access tokens in input contstrained devices, such as TV's or consoles. It offers an out of band approach where the user can authenticate and authorize access on in a browser on a phone or a computer while logging in to the device. |
RFC7519 | JSON Web Token (JWT) | JSON Web Tokens are a core part of OpenID Connect and later also OAuth. They provide a JSON based token format that can be signed or encrypted. This is the base specification for JWTs. |
RFC7521 | Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants | This specification defines a basic framework for alternate client and user authentication methods based on assertions. It aims to provide interoperability between OAuth 2.0 and other identity systems. |
RFC7523 | JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants | This specification implements RFC7521 and adds a new grant type where the client can provide an assertion in JWT format that proves that the user is authenticated. It also adds a new client authentication mechanism in which the client can prove its identity by providing a JWT as well. |
RFC8705 | OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens | Mutual-TLS provides a powerful way to authenticate a client. This specification standardizes the usage of Mutual TLS together with OAuth. It also adds the possiblility to create Proof of Possession tokens instead of Bearer tokens by binding the access token to the certificate that was used to authenticate the client. This way the token can only be used by the client that also possesses the client certificate. |
RFC8252 | OAuth 2.0 for Native Apps | This is a description of how to use OAuth together with native Apps, specifically on mobile devices. |
RFC7800 | Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) | Proof of Possession is a pattern for how to bind a token to some proof that only the client can provide. This changes the token from being a bearer token to a PoP token. The purpose of PoP is to prevent a lost or stolen token from being possible to use by anyone else than the client it was issued to. |
RFC6750 | The OAuth 2.0 Authorization Framework: Bearer Token Usage | Bearer token usage provides a definition of how to use Bearer tokens when accessing APIs. |
RFC7591 | OAuth 2.0 Dynamic Client Registration Protocol | This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. |
RFC7636 | Proof Key for Code Exchange by OAuth Public Clients (PKCE) | OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange (PKCE, pronounced "pixy"). |
JWT Response for OAuth Token Introspection | JWT Response for OAuth Token Introspection | This draft proposes an additional JSON Web Token (JWT) based response for OAuth 2.0 Token Introspection. |
OAuth 2.0 Assisted Token | OAuth 2.0 Assisted Token | The OAuth 2.0 authorization flow for Single Page Applications (SPAs), often referred to as the assisted token flow, enables OAuth clients to request user authorization written in scripting languages, like JavaScript, with a simplified integration compared to the implicit grant type flow. |
HEART Profile for OAuth 2.0 | Health Relationship Trust Profile for OAuth 2.0 | The HEART Profile defines a security baseline for OAuth 2.0 suitable for use cases in the healthcare domain but not limited to. |
OpenID Connect
OpenID Connect is an identity layer on top of the OAuth authorization standard protocol. It allows for verification of an end user’s identity based on authentication performed by an authorization server. The Curity Identity Server has been self-certified to comply with all of the OpenID Connect protocols.
| RFC or Spec | Name | Purpose of Standard |
|---|---|---|
Core | OpenID Connect Core 1.0 | This specification defines the core OpenID Connect functionality: authentication built on top of OAuth 2.0 and the use of Claims to communicate information about the End-User. It also describes the security and privacy considerations for using OpenID Connect. |
Discovery | OpenID Connect Discovery 1.0 | This specification defines a mechanism for an OpenID Connect Relying Party to discover the End-User's OpenID Provider and obtain information needed to interact with it, including its OAuth 2.0 endpoint locations. |
DCR | OpenID Connect Dynamic Client Registration 1.0 | This specification defines how an OpenID Connect Relying Party can dynamically register with the End-User's OpenID Provider, providing information about itself to the OpenID Provider, and obtaining information needed to use it, including the OAuth 2.0 Client ID for this Relying Party. |
Multiple Response Types | OAuth 2.0 Multiple Response Type Encoding Practices | This specification also defines a Response Mode Authorization Request parameter that informs the Authorization Server of the mechanism to be used for returning Authorization Response parameters from the Authorization Endpoint. |
Form Post Response Mode | OAuth 2.0 Form Post Response Mode | This specification defines the Form Post Response Mode. In this mode, Authorization Response parameters are encoded as HTML form values that are auto-submitted in the User Agent, and thus are transmitted via the HTTP POST method to the Client, with the result parameters being encoded in the body using the application/x-www-form-urlencoded format. |
Session Management | OpenID Connect Session Management 1.0 | This document describes how to manage sessions for OpenID Connect, including when to log out the End-User. |
Front Channel Logout | OpenID Connect Front-Channel Logout 1.0 | This specification defines a logout mechanism that uses front-channel communication via the User Agent between the OP and RPs being logged out that does not need an OpenID Provider iframe on Relying Party pages. |
Back Channel Logout | OpenID Connect Back-Channel Logout 1.0 | This specification defines a logout mechanism that uses direct back-channel communication between the OP and RPs being logged out; this differs from front-channel logout mechanisms, which communicate logout requests from the OP to RPs via the User Agent. |
CIBA | OpenID Connect Client Initiated Backchannel Authentication Flow | The Client Initiated Backchannel Authentication specification extends OpenID Connect to define a decoupled flow where authentication can be initiated on one device and carried out at another. |
FAPI 1.0 - Part 1: Baseline | Financial-grade API Security Profile 1.0 - Part 1: Baseline | This document is Part 1 of FAPI that specifies the Financial-grade API and it provides a profile of OAuth that is suitable to be used in the access of read-only financial data and similar use cases. |
FAPI 1.0 - Part 2: Advanced | Financial-grade API Security Profile 1.0 - Part 2: Advanced | This document is Part 2 of FAPI that specifies the Financial-grade API and it provides a profile of OAuth that is suitable to be used in write access to financial data (also known as transaction access) and other similar higher risk access. |
FAPI: CIBA Profile | Financial-grade API: Client Initiated Backchannel Authentication Profile | This document provides security recommendations for using CIBA with Financial-grade APIs. |
FAPI: JARM | Financial-grade API: JWT Secured Authorization Response Mode (JARM) | This specification ensures that authorization respond data is tamperproof. It does this by packing it together into a JWT. This JWT can be signed, so that the client application can integrity check it. It can also be encrypted. These protections provide safeguards against untrusted intermediaries. |
SCIM
System for Cross-domain Identity Management (SCIM) is a standardized and powerful way to perform Create, Read, Update and Delete (CRUD) actions to manage users. The Curity Identity Server utilizes SCIM to hide the complexity of communicating with user account stores behind a standardized interface.
| RFC or Spec | Name | Purpose of Standard |
|---|---|---|
RFC7643 | System for Cross-domain Identity Management: Core Schema | The System for Cross-domain Identity Management (SCIM) specifications are designed to make identity management in cloud-based applications and services easier. This document provides a platform-neutral schema and extension model for representing users and groups and other resource types in JSON format. This schema is intended for exchange and use with cloud service providers. |
RFC7644 | System for Cross-domain Identity Management: Protocol | The System for Cross-domain Identity Management (SCIM) specification is an HTTP-based protocol that makes managing identities in multi-domain scenarios easier to support via a standardized service. SCIM's intent is to reduce the cost and complexity of user management operations by providing a common user schema, an extension model, and a service protocol defined by this document. |
Core 1.1 | System for Cross-Domain Identity Management: Core Schema 1.1 | The System for Cross-Domain Identity Management (SCIM) specification is designed to make managing user identity in cloud based applications and services easier. The specification suite builds upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. |
Protocol 1.1 | System for Cross-Domain Identity Management:Protocol 1.1 | The SCIM Protocol is an application-level, REST protocol for provisioning and managing identity data on the web. The protocol supports creation, modification, retrieval, and discovery of core identity Resources; i.e., Users and Groups, as well as custom Resource extensions. |
Authentication
The Curity Identity Server also facilitates conformance to authentication specifications such as WebAuthn, Time-Based One-Time Password Algorithm (TOTP) and HMAC-Based One-Time Password Algorithm (HOTP).
| RFC or Spec | Name | Purpose of Standard |
|---|---|---|
WebAuthn | FIDO2: Web Authentication (WebAuthn) | This specification defines an API enabling the creation and use of strong, attested, scoped, public key-based credentials by web applications, for the purpose of strongly authenticating users. |
RFC6238 | TOTP: Time-Based One-Time Password Algorithm | This document describes an extension of the One-Time Password (OTP) algorithm, namely the HMAC-based One-Time Password (HOTP) algorithm, as defined in RFC 4226, to support the time-based moving factor. |
RFC4226 | HOTP: An HMAC-Based One-Time Password Algorithm | This document describes an algorithm to generate one-time password values, based on Hashed Message Authentication Code (HMAC). |
SAML | SAML Web Browser SSO profile | This specification defines a way to federate upstream to a different SAML Identity Provider (IdP) or downstream to a SAML Server Provider (SP) |
Configuration
There are also other protocols used in the Curity Identity Server, used for configuration, access control and alarms for example.
| RFC or Spec | Name | Purpose of Standard |
|---|---|---|
RFC8040 | RESTCONF Protocol | This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). |
RFC6020 | YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) | YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. |
RFC8632 | A YANG Data Model for Alarm Management | This document defines a YANG module for alarm management. It includes functions for alarm-list management, alarm shelving, and notifications to inform management systems. There are also operations to manage the operator state of an alarm and administrative alarm procedures. The module carefully maps to relevant alarm standards. |
RFC6536 | Network Configuration Protocol (NETCONF) Access Control Model | The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF protocol access for particular users to a pre-configured subset of all available NETCONF protocol operations and content. This document defines such an access control model. |
See Curity Identity Server in action
In this demo, we give you a comprehensive overview of the Curity Identity Server. What it is and what problems it helps you solve.
Watch Demo
