# Implemented technologies and standards

Abblix OIDC Server implements the OAuth 2.0, [OpenID Connect](https://www.abblix.com/en/docs/glossary-overview#openid-connect), and JWT standards listed below. The server is certified by the OpenID Foundation across all login and logout profiles, with zero failures and zero skipped tests in 600+ conformance checks.

## OAuth 2.0 core standards

- **The OAuth 2.0 Authorization Framework**: [RFC 6749](https://datatracker.ietf.org/doc/html/rfc6749): Defines procedures for secure authorization of applications including authorization code, implicit, client credentials, and resource owner password credentials flows.
- **The OAuth 2.0 Authorization Framework: [Bearer Token Usage](https://www.abblix.com/en/docs/glossary-overview#bearer-token-usage)**: [RFC 6750](https://datatracker.ietf.org/doc/html/rfc6750): Secures protected resource access with bearer tokens, including compliant authentication challenges and proper HTTP status code mapping for token errors.
- **HTTP Semantics: Authentication**: [RFC 9110, Section 11](https://datatracker.ietf.org/doc/html/rfc9110#section-11): Ensures all `401` responses include authentication challenges matching the client's authentication scheme.
- **OAuth 2.0 [Token Revocation](https://www.abblix.com/en/docs/glossary-overview#token-revocation)**: [RFC 7009](https://datatracker.ietf.org/doc/html/rfc7009): Describes methods to securely invalidate access and refresh tokens.
- **OAuth 2.0 [Token Introspection](https://www.abblix.com/en/docs/glossary-overview#token-introspection)**: [RFC 7662](https://datatracker.ietf.org/doc/html/rfc7662): Allows resource servers to verify the active state and metadata of tokens.
- **JWT Response for OAuth Token Introspection**: [RFC 9701](https://datatracker.ietf.org/doc/html/rfc9701): Returns the token introspection response as a signed and optionally encrypted JWT, letting the requesting party verify the response's origin and integrity.
- **[Proof Key for Code Exchange](https://www.abblix.com/en/docs/glossary-overview#pkce) (PKCE)**: [RFC 7636](https://datatracker.ietf.org/doc/html/rfc7636): Improves security for public clients during authorization code exchange.
- **OAuth 2.0 [Device Authorization Grant](https://www.abblix.com/en/docs/glossary-overview#device-authorization-grant)**: [RFC 8628](https://datatracker.ietf.org/doc/html/rfc8628): Enables OAuth 2.0 authorization on devices with limited input capabilities (smart TVs, game consoles, IoT devices) by delegating user interaction to a secondary device.
- **OAuth 2.0 [Dynamic Client Registration](https://www.abblix.com/en/docs/glossary-overview#dynamic-client-registration) Protocol**: [RFC 7591](https://datatracker.ietf.org/doc/html/rfc7591): Provides mechanisms for clients to register dynamically with authorization servers.
- **OAuth 2.0 Dynamic Client Registration Management Protocol**: [RFC 7592](https://datatracker.ietf.org/doc/html/rfc7592): Enables management operations (read, update, delete) for dynamically registered clients.
- **OAuth 2.0 Token Exchange**: [RFC 8693](https://datatracker.ietf.org/doc/html/rfc8693): Allows a client to exchange a security token for a different one, enabling delegation and impersonation flows across services.
- **OAuth 2.0 [Mutual-TLS Client Authentication](https://www.abblix.com/en/docs/glossary-overview#mutual-tls-client-authentication) and Certificate-Bound Access Tokens**: [RFC 8705](https://datatracker.ietf.org/doc/html/rfc8705): Provides mutual TLS authentication with PKI and self-signed certificate validation, plus certificate-bound tokens.
- **OAuth 2.0 [Resource Indicators](https://www.abblix.com/en/docs/glossary-overview#resource-indicators-for-oauth-2-0)**: [RFC 8707](https://datatracker.ietf.org/doc/html/rfc8707): Enables clients to specify the resources they want access to.
- **[JSON Web Token](https://www.abblix.com/en/docs/glossary-overview#jwt) (JWT) Profile for OAuth 2.0 Access Tokens**: [RFC 9068](https://datatracker.ietf.org/doc/html/rfc9068): Specifies the use of JWTs as OAuth 2.0 access tokens.
- **[JWT-Secured Authorization Request](https://www.abblix.com/en/docs/glossary-overview#jar) (JAR)**: [RFC 9101](https://datatracker.ietf.org/doc/html/rfc9101): Passes authorization request parameters in a JWT that may be signed and optionally encrypted, protecting their integrity and confidentiality.
- **[JWT Secured Authorization Response Mode](https://www.abblix.com/en/docs/glossary-overview#jarm) (JARM)**: [JARM](https://openid.net/specs/oauth-v2-jarm-final.html): Returns the authorization response parameters in a JWT that may be signed and optionally encrypted, protecting their integrity and confidentiality.
- **OAuth 2.0 [Pushed Authorization Requests](https://www.abblix.com/en/docs/glossary-overview#par) (PAR)**: [RFC 9126](https://datatracker.ietf.org/doc/html/rfc9126): Lets clients push authorization request parameters directly to the authorization server instead of passing them through the browser.
- **OAuth 2.0 Authorization Server Issuer Identification**: [RFC 9207](https://datatracker.ietf.org/doc/html/rfc9207): Ensures the authenticity of authorization servers to clients.
- **OAuth 2.0 [Rich Authorization Requests](https://www.abblix.com/en/docs/glossary-overview#rich-authorization-requests) (RAR)**: [RFC 9396](https://datatracker.ietf.org/doc/html/rfc9396): Lets clients request fine-grained authorization for specific operations, beyond the coarse-grained `scope` parameter.
- **OAuth 2.0 Demonstrating Proof of Possession (DPoP)**: [RFC 9449](https://datatracker.ietf.org/doc/html/rfc9449): Sender-constrains access tokens by binding each one to a public key the client proves possession of on every request, so a stolen token is unusable without the corresponding private key.
- **OAuth 2.0 Multiple Response Type Encoding Practices**: [Specification](https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html): Encodes different response types in OAuth 2.0 requests.
- **OAuth 2.0 Form Post Response Mode**: [Specification](https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html): Transmits OAuth 2.0 responses via HTTP form posts.

## JSON web standards

- **[JSON Web Signature](https://www.abblix.com/en/docs/glossary-overview#jws) (JWS)**: [RFC 7515](https://datatracker.ietf.org/doc/html/rfc7515): Defines digital signature and MAC methods for JSON data structures.
- **[JSON Web Encryption](https://www.abblix.com/en/docs/glossary-overview#jwe) (JWE)**: [RFC 7516](https://datatracker.ietf.org/doc/html/rfc7516): Defines encryption methods for JSON data structures.
- **JSON Web Key ([JWK](https://www.abblix.com/en/docs/glossary-overview#jwk))**: [RFC 7517](https://datatracker.ietf.org/doc/html/rfc7517): Defines a JSON representation of cryptographic keys.
- **[JSON Web Algorithms](https://www.abblix.com/en/docs/glossary-overview#jwa) (JWA)**: [RFC 7518](https://datatracker.ietf.org/doc/html/rfc7518): Defines cryptographic algorithms for use with JWS, JWE, and JWK.
- **JSON Web Token (JWT)**: [RFC 7519](https://datatracker.ietf.org/doc/html/rfc7519): Defines the structure and use of JWTs for representing claims securely.
- **JWT Profile for OAuth 2.0 [Client Authentication](https://www.abblix.com/en/docs/glossary-overview#client-authentication) and Authorization Grants**: [RFC 7523](https://datatracker.ietf.org/doc/html/rfc7523): Uses JWTs for secure client authentication (private_key_jwt, client_secret_jwt) and as authorization grants.
- **Authentication Method Reference Values**: [RFC 8176](https://datatracker.ietf.org/doc/html/rfc8176): Defines standardized values for the `amr` ([Authentication Methods References](https://www.abblix.com/en/docs/glossary-overview#amr)) JWT claim, enabling interoperable communication of authentication methods (password, OTP, biometrics, MFA, smart card, etc.).
- **Security Event Token (SET)**: [RFC 8417](https://datatracker.ietf.org/doc/html/rfc8417): Describes security- and identity-related events, such as token revocation or account changes, as statements of fact about a subject, carried in a JWT that can be signed and optionally encrypted.
- **Subject Identifiers for Security Event Tokens**: [RFC 9493](https://datatracker.ietf.org/doc/html/rfc9493): Defines named JSON formats for identifying the subject a security event refers to - by issuer and subject pair, email address, phone number, opaque identifier, and other registered formats.
- **Push-Based Security Event Token (SET) Delivery Using HTTP**: [RFC 8935](https://datatracker.ietf.org/doc/html/rfc8935): Delivers security event tokens by HTTP POST from the transmitter to an endpoint the receiver hosts, with acknowledgement or a structured error returned in the response.
- **Poll-Based Security Event Token (SET) Delivery Using HTTP**: [RFC 8936](https://datatracker.ietf.org/doc/html/rfc8936): Lets a receiver fetch pending security event tokens from the transmitter and acknowledge the ones it has secured, for receivers that cannot host an endpoint of their own.

## OpenID Connect specifications

- **OpenID Connect Core 1.0**: [Specification](https://openid.net/specs/openid-connect-core-1_0.html): Core functionality for OpenID Connect identity layer over OAuth 2.0, including [ID Token](https://www.abblix.com/en/docs/glossary-overview#id-token-identity-token) issuance, standard claims, and authentication flows.
- **OpenID Connect Discovery 1.0 / OAuth 2.0 Authorization Server Metadata**: [Specification](https://openid.net/specs/openid-connect-discovery-1_0.html), [RFC 8414](https://datatracker.ietf.org/doc/html/rfc8414): Enables clients to discover provider configurations dynamically via the well-known endpoint.
- **OpenID Connect Dynamic Client Registration 1.0**: [Specification](https://openid.net/specs/openid-connect-registration-1_0.html): Enables OpenID Connect clients to register dynamically with providers.
- **OpenID Connect Session Management 1.0**: [Specification](https://openid.net/specs/openid-connect-session-1_0.html): Manages user session states in identity providers with check_session_iframe support.
- **OpenID Connect [RP-Initiated Logout](https://www.abblix.com/en/docs/glossary-overview#rp-initiated-logout) 1.0**: [Specification](https://openid.net/specs/openid-connect-rpinitiated-1_0.html): Details logout initiated by relying parties via the end-session endpoint.
- **OpenID Connect [Front-Channel Logout](https://www.abblix.com/en/docs/glossary-overview#front-channel-logout) 1.0**: [Specification](https://openid.net/specs/openid-connect-frontchannel-1_0.html): Handles logout requests through [front-channel communication](https://www.abblix.com/en/docs/glossary-overview#front-channel-communication).
- **OpenID Connect [Back-Channel Logout](https://www.abblix.com/en/docs/glossary-overview#back-channel-logout) 1.0**: [Specification](https://openid.net/specs/openid-connect-backchannel-1_0.html): Manages logout processes using [back-channel communication](https://www.abblix.com/en/docs/glossary-overview#back-channel-communication) with logout tokens.
- **OpenID Connect [Client-Initiated Backchannel Authentication](https://www.abblix.com/en/docs/glossary-overview#ciba) (CIBA)**: [Specification](https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html): Enables secure user authentication via backchannel communication on devices without direct web access, commonly used in IoT and financial-services scenarios. Supports three delivery modes: poll (client polls [token endpoint](https://www.abblix.com/en/docs/glossary-overview#token-endpoint)), ping (server notifies client at callback), and push (server delivers tokens to notification endpoint).
- **Pairwise Pseudonymous Identifiers ([PPID](https://www.abblix.com/en/docs/glossary-overview#ppid))**: [OpenID Connect Core Section 8](https://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg): Implements a privacy mechanism by generating unique subject identifiers per client.

## Shared Signals specifications

- **OpenID [Shared Signals Framework](https://www.abblix.com/en/docs/glossary-overview#ssf) 1.0 (SSF)**: [Specification](https://openid.net/specs/openid-sharedsignals-framework-1_0.html): Defines managed event streams through which a transmitter continuously shares security events with a receiver - stream configuration and status, subject management, stream verification, and delivery over push or poll.
- **OpenID [Continuous Access Evaluation Profile](https://www.abblix.com/en/docs/glossary-overview#caep) 1.0 (CAEP)**: [Specification](https://openid.net/specs/openid-caep-1_0.html): Defines events describing changes to a subject's sessions and access context after the initial login - a revoked session, a changed credential, a shifted assurance or risk level - so cooperating services can react without waiting for the next authentication.
- **OpenID [RISC](https://www.abblix.com/en/docs/glossary-overview#risc) Profile 1.0**: [Specification](https://openid.net/specs/openid-risc-1_0.html): Defines events for coordinating responses to account risk incidents - credential compromise, account disabling and deletion, identifier changes, and recovery activity - so an incident detected at one provider can protect the same user everywhere.

## Client authentication methods

The server supports all standard client authentication methods:
- **client_secret_basic** - HTTP Basic authentication with client credentials
- **client_secret_post** - Client credentials in POST body
- **client_secret_jwt** - HMAC-signed JWT assertion
- **private_key_jwt** - RSA/EC-signed JWT assertion
- **tls_client_auth** - PKI mutual TLS authentication
- **self_signed_tls_client_auth** - Self-signed certificate mutual TLS
- **none** - Public clients without authentication