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 SpecNamePurpose of Standard


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).


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.


The OAuth 2.0 Authorization FrameworkThe 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


OAuth 2.0 Token IntrospectionThis 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


OAuth 2.0 Token RevocationToken revocation allows the client to revoke issued tokens by calling the revoke endpoint on the OAuth Server


OAuth 2.0 Device Authorization GrantThis 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.


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.


Assertion Framework for OAuth 2.0 Client Authentication and Authorization GrantsThis 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.


JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization GrantsThis 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.


OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access TokensMutual-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.


OAuth 2.0 for Native AppsThis is a description of how to use OAuth together with native Apps, specifically on mobile devices.


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.


The OAuth 2.0 Authorization Framework: Bearer Token UsageBearer token usage provides a definition of how to use Bearer tokens when accessing APIs.


OAuth 2.0 Dynamic Client Registration ProtocolThis specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers.


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 IntrospectionThis 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 TokenThe 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.0The 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

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 SpecNamePurpose of Standard


OpenID Connect Core 1.0This 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.


OpenID Connect Discovery 1.0This 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.


OpenID Connect Dynamic Client Registration 1.0This 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 PracticesThis 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 ModeThis 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.0This 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.0This 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.0This 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.


OpenID Connect Client Initiated Backchannel Authentication FlowThe 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: BaselineThis 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: AdvancedThis 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 ProfileThis document provides security recommendations for using CIBA with Financial-grade APIs.


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.


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 SpecNamePurpose of Standard


System for Cross-domain Identity Management: Core SchemaThe 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.


System for Cross-domain Identity Management: ProtocolThe 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.1The 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.1The 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.


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 SpecNamePurpose of Standard


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.


TOTP: Time-Based One-Time Password AlgorithmThis 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.


HOTP: An HMAC-Based One-Time Password AlgorithmThis document describes an algorithm to generate one-time password values, based on Hashed Message Authentication Code (HMAC).


SAML Web Browser SSO profileThis specification defines a way to federate upstream to a different SAML Identity Provider (IdP) or downstream to a SAML Server Provider (SP)


There are also other protocols used in the Curity Identity Server, used for configuration, access control and alarms for example.

RFC or SpecNamePurpose of Standard


RESTCONF ProtocolThis 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).


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.


A YANG Data Model for Alarm ManagementThis 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.


Network Configuration Protocol (NETCONF) Access Control ModelThe 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.