Specifications
A page of this site cites the specification it describes by number and section, so you can read the source
rather than this paraphrase of it. The table below is the index.
OAuth 2.0
Specification
What it brings
Page
RFC 6749
The framework: clients, authorization requests, grants
Authorization request
RFC 6750
Bearer tokens on a resource server
Access tokens
RFC 7009
Token revocation
Introspection and revocation
RFC 7521, RFC 7523
Client authentication and grants by JWT assertion
Client authentication , JWT bearer
RFC 7591, RFC 7592
Dynamic client registration, and managing a registration
Dynamic registration
RFC 7636
PKCE, mandatory here, S256 only
Authorization request
RFC 7662
Token introspection
Introspection and revocation
RFC 8414
Authorization server metadata
Discovery and JWKS
RFC 8628
The device authorization grant
Device code
RFC 8693
Token exchange, delegation and impersonation
Token exchange
RFC 8705
Mutual TLS client authentication and certificate-bound tokens
Mutual TLS
RFC 8707
Resource indicators, the audience a client asks for
Resources
RFC 9068
The JWT profile of access tokens, at+jwt
Access tokens
RFC 9101
Request objects, the signed authorization request
Request objects
RFC 9126
Pushed authorization requests
Pushed authorization requests
RFC 9207
iss in the authorization response, alwaysAuthorization request
RFC 9396
Rich authorization requests, authorization_details
Authorization details
RFC 9449
DPoP, a token bound to a key the client proves it holds
DPoP
RFC 8725 (JSON Web Token best current practices) and RFC 9700 (OAuth 2.0 security best current practice)
are not features; they are the rules the rest is written against. Secure by
default says which of their recommendations are properties of the
code here.
OpenID Connect
Specification
What it brings
Page
OpenID Connect Core 1.0
ID tokens, UserInfo, claims, prompt, acr, max_age
OAuth 2.0 and OpenID Connect
OpenID Connect Discovery 1.0
/.well-known/openid-configurationDiscovery and JWKS
OpenID Connect Dynamic Registration 1.0
Registration, the OIDC reading of it
Dynamic registration
RP-Initiated Logout 1.0
A client asking for a session to end
Logout
Front-Channel Logout 1.0
Telling the other clients through the browser
Logout
Back-Channel Logout 1.0
Telling them server to server, with a logout token
Logout
JARM
A signed, and optionally encrypted, authorization response
Response modes
CIBA Core 1.0
The decoupled flow, where the device that asks is not the one that answers
Backchannel authentication
FAPI 2.0 Security Profile, FAPI 2.0 Message Signing
The profile open banking actually deploys
Conformance
Credentials
Specification
What it brings
Page
W3C Web Authentication Level 3
Passkeys, enrolment and assertion
Passkeys
RFC 4226, RFC 6238
HOTP and TOTP, the second factor from an application
TOTP
RFC 7517, RFC 7515, RFC 7516, RFC 7518, RFC 7519
JOSE: keys, signatures, encryption, algorithms, claims
Keys
What is deliberately not implemented
Specification
Why
The implicit flow and the hybrid response types that carry a token in a fragment
Tokens in a URL are read by history, logs and referrers. OIDC Core keeps them, Beffroi does not
The resource owner password credentials grant
It teaches applications to collect passwords
PKCE with plain
It protects nothing against an attacker who can read the request
OpenID Connect Session Management 1.0
It rests on third party cookies in an iframe, which browsers no longer allow. Front-channel and back-channel logout do the job
What is not implemented yet
SCIM (RFC 7643, RFC 7644) and SAML 2.0 with XML Signature and XML Encryption are planned, and each has a
page saying what is decided so far: SCIM , SAML 2.0 . OpenID
Federation, the shared signals family, verifiable credentials and the other drafts are tracked without a
date, and none of them is announced as coming.