Core

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

Dynamic Client Registration

(Optional) Defines how clients dynamically register with OpenID Providers

Discovery

(Optional) Defines how Clients dynamically discover information about OpenID Providers

Logout

(Optional) Defines how a Relying Party requests that an OpenID Provider log out the End-User

FAPI Part 1

It specifies a baseline security profile of OAuth that is suitable for protecting APIs with a moderate inherent risk. Importantly, this profile does not provide non-repudiation (signing of authorization requests and responses) and sender-constrained access tokens.

FAPI Part 2

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.

JARM

Defines a new response mode ( response_mode ) where all parameters are packaged into a JWT that is signed by the OpenID Provider / Authorization Server. This naturally also includes the parameters of error responses and any present and future OAuth 2.0 and OpenID Connect extensions.

CIBA

Client-Initiated Backchannel Authentication (CIBA) is a new authentication flow in which RPs, that can obtain a valid identifier for the user they want to authenticate, will be able to initiate an interaction flow to authenticate their users without having end-user interaction from the consumption device.

RFC-6749

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

RFC-9126

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.

RFC7800

Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)

This specification describes how to declare in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular proof-of- possession key and how the recipient can cryptographically confirm proof of possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key.

RFC 8252

OAuth 2.0 for Native Apps

OAuth 2.0 authorization requests from native apps should only be made through external user-agents, primarily the user’s browser. This specification details the security and usability reasons why this is the case and how native apps and authorization servers can implement this best practice.

RFC 8705

OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens

OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client’s mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token

RFC 7591

OAuth 2.0 Dynamic Client Registration Protocol

This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration.

RFC 8414

OAuth 2.0 Authorization Server Metadata

This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities.

RFC 8628

OAuth 2.0 Device Authorization Grant

The OAuth 2.0 device authorization grant is designed for Internet- connected devices that either lack a browser to perform a user-agent- based authorization or are input constrained to the extent that requiring the user to input text in order to authenticate during the authorization flow is impractical. It enables OAuth clients on such devices (like smart TVs, media consoles, digital picture frames, and printers) to obtain user authorization to access protected resources by using a user agent on a separate device.

RFC 9068

JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens

This specification defines a profile for issuing OAuth 2.0 access tokens in JSON Web Token (JWT) format. Authorization servers and resource servers from different vendors can leverage this profile to issue and consume access tokens in an interoperable manner.

RFC7662

OAuth 2.0 Token Introspection

This specification defines a method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of an OAuth 2.0 token and to determine meta-information about this token. OAuth 2.0 deployments can use this method to convey information about the authorization context of the token from the authorization server to the protected resource.

Draft DPOP

Internet-Draft OAuth DPoP

This document outlines an application-level sender-constraining for access and refresh tokens that can be used in cases where neither mTLS nor OAuth Token Binding are available.

Draft
RAR

Draft: OAuth 2.0 Rich Authorization Requests

The Rich Authorization Requests extension provides a way for OAuth clients to request fine-grained permissions during an authorization request. For example, an app may specify a request such as “let me make a payment of 45 Euros” or “please give me read access to folder X and write access to folder Y”.

User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization

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.

https://gluu.co/uma-grantgluu.co

User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization

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.