Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

RFC Support Reference

This chapter lists every standard that Ahdapa implements, the implementation scope, and any known limitations.

OAuth 2.0 core

RFCTitleStatusNotes
RFC 6749OAuth 2.0 Authorization FrameworkFull
RFC 9700OAuth 2.0 Security Best Current PracticeFull
RFC 6750Bearer Token UsageFull
RFC 7009Token RevocationFullRevocation invalidates the entire token family; the JTI blocklist is propagated to all cluster nodes via CRDT gossip.
RFC 7636PKCEFullplain method intentionally not supported.
RFC 8693Token ExchangeFullFull OBO flow including actor_token validation, act claim chains, three-way scope intersection, delegation target guards (delegation_targets / delegation_target_category), and HBAC enforcement. Impersonation (acting as a different user without a subject token) is not supported.
RFC 8707Resource IndicatorsFull
RFC 8628Device Authorization GrantFull
RFC 9126Pushed Authorization RequestsFull
RFC 9207Authorization Server Issuer IdentificationFull
RFC 8705OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access TokensFullWhen DPoP and mTLS are both active, cnf.jkt and cnf.x5t#S256 are both present in the same cnf object. In cluster mode the client-certificate thumbprint is carried in the internal auth-code payload so the origin node embeds it in the access token without re-seeing the certificate.
RFC 9449DPoPFull

JWT and JOSE

RFC / DraftTitleStatusNotes
RFC 7519JSON Web Token (JWT)Full
RFC 7521Assertion FrameworkFull
RFC 7523JWT Client AuthenticationFull
RFC 9068JWT Profile for Access TokensFull
draft-ietf-jose-fully-specified-algorithmsML-DSA algorithm IDsAdvertisedKey generation and signing use ML-DSA-44, ML-DSA-65, and ML-DSA-87 via native-ossl.

OpenID Connect

SpecificationStatusNotes
OIDC Core 1.0FullPairwise subject identifiers (HMAC-SHA256, per-client sector key). acr_values_supported includes Kerberos (FreeIPA-authenticated sessions). ID tokens may be signed with ML-DSA-65.
OIDC Discovery 1.0Fullscopes_supported and claims_supported are rebuilt from the CRDT scope definitions on every request.
OIDC Federation 1.0PartialSelf-signed Entity Statement published at /.well-known/openid-federation; bilateral trust via pre-configured [federation].trusted_issuers. Full trust-chain walking not yet implemented.

ACME Token Authority

RFC / SpecTitleStatusNotes
RFC 9447ACME Token Binding for tkauth-01Full — Kerberos issuance pathToken Authority endpoint at POST /at/account/{id}/token. Authentication is Kerberos SPNEGO only; constraint values are derived from the authenticated Kerberos principal — this is a Kerberos-identity binding, not the telephony tnauthlist profile. Advertised in discovery as token_authority_endpoint when [gssapi] is configured. Only tktype = "JWTClaimConstraints" is accepted.
RFC 8226 §6.2JWTClaimConstraints X.509 extensionFull — Kerberos constraint variantUsed as the authority token constraint encoding format. The permittedValues fields bind Kerberos-specific claims: sub carries the authenticated Kerberos principal (e.g. alice@IPA.TEST), iss carries the server issuer URL, and (for host/service principals) dns carries the IPA-managed FQDNs for that principal. This is distinct from the telephony tnauthlist use of the same extension.
RFC 9118EnhancedJWTClaimConstraintsFullAhdapa builds and DER-encodes an EnhancedJWTClaimConstraints structure. mustInclude is set to ["sub"], requiring the ACME server to reject any PASSporT that omits the sub claim. permittedValues binds sub to the Kerberos principal, iss to the server issuer URL, and (for host/service principals) dns to the IPA-managed FQDNs returned by an LDAP subtree search against cn=accounts for objects with managedBy pointing to the principal’s DN. The base64url-encoded DER is carried as tkvalue in the signed authority token JWT. mustExclude is supported by the ASN.1 codec but is not populated in the current issuance path.

Discovery and metadata

RFCStatus
RFC 8414 (AS Metadata)Full — /.well-known/oauth-authorization-server

Signing algorithms

The following algorithms are advertised in the discovery document and accepted for client authentication (private_key_jwt; client_secret_jwt uses HMAC-SHA2 only):

  • Classical: RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384, ES512, EdDSA
  • Post-quantum: ML-DSA-44, ML-DSA-65, ML-DSA-87

The default signing algorithm for tokens issued by the server is ES256 (ECDSA P-256). The algorithm is configurable via [server] jwt_signing_algorithm; changing it on an existing deployment triggers automatic key rotation on the next startup, with the old public key retained for backward verification. The active signing key is rotatable via the admin API and propagates to all cluster nodes automatically.

ID tokens are signed with one of: RS256, ES256, EdDSA, ML-DSA-65.

Token endpoint client authentication methods

MethodStatus
private_key_jwtFull — accepted at /token, device grant polling, and /par
client_secret_jwtFull — accepted at /token, device grant polling, and /par
client_secret_basicFull
client_secret_postFull
noneSupported for public clients
tls_client_authFull (RFC 8705)
self_signed_tls_client_authFull (RFC 8705)
kerberos_client_authFull (FreeIPA extension) — client presents a Kerberos AP-REQ in Authorization: Negotiate; SPNEGO is verified server-side; principal matched against a registered exact value or glob pattern. Accepted at /token, /device_authorization, /revoke, and /introspect. Advertised in discovery only when [gssapi] is configured. Not available via dynamic client registration. See Kerberos client authentication for setup.

WebAuthn / Passkeys

SpecificationStatusNotes
W3C WebAuthn Level 2 §7.2 (assertion)FullCredentials are merged from FreeIPA LDAP (ipa passkey-register) and the server’s own database at assertion time.
W3C WebAuthn Level 2 §7.1 (registration)Full
FIDO MDS / attestation statement verificationNot implementedAttestation statements are accepted without verifying the FIDO Metadata Service signature. The public key embedded in authData is trusted directly. This is acceptable for a controlled Relying Party that does not assert authenticator model claims.

Passkey login is enabled by setting ipa.passkey_rp_id in the configuration.

Supported COSE key types: EC2/P-256 (ES256), OKP/Ed25519 (EdDSA), RSA (RS256).

Known limitations

  • RFC 7523 urn:ietf:params:oauth:grant-type:jwt-bearer — JWKS URI required: The client must have a jwks_uri registered; inline JWKS is not supported. The assertion iss must be present in [federation].trusted_issuers (or resolvable via a trust-chain anchor); it does not need to equal the requesting client’s client_id.
  • RFC 7591 Dynamic Client Registration: Client CRUD is available via the admin API (/api/admin/clients). The public POST /register endpoint is gated by the server.registration_token configuration key; when that key is absent, /register returns 404. Full RFC 7591 §3 initial-access-token issuance flow is not implemented.
  • Token Exchange (RFC 8693) impersonation: Full OBO delegation with actor_token is supported. Pure impersonation (acting as a different user without a subject token carrying that user’s identity) is not supported.
  • OIDC Federation 1.0 — bilateral trust only: The server publishes a spec-compliant Entity Statement at /.well-known/openid-federation. Incoming federated assertions are validated against pre-configured trusted_issuers only. Full trust-chain resolution (intermediaries, metadata_policy merging) is not implemented.
  • kerberos_client_auth — HBAC hostgroup membership not yet resolved: When kerberos_hbac_service is set on a Kerberos client, HBAC rules that match the machine principal by individual hostname work correctly. Rules that match by hostgroup currently evaluate as deny because group membership for Kerberos machine principals is not yet resolved at token time. Use individual host rules in the HBAC service instead of hostgroup-based rules until this limitation is lifted.
  • Wrapping key distribution: The cluster wrapping key is stored locally on each node; only its UUID is gossiped. When a node sees an unfamiliar UUID it fetches the raw key via GET /api/gossip/wrapping-key, which returns a CMS EnvelopedData blob sealed to the requesting node’s ML-KEM-768 public key. Gossip sync messages themselves are wrapped in CMS SignedData(EnvelopedData) (ECDSA P-256 outer signature, ML-KEM-768 inner encryption per recipient). Restrict /api/gossip/sync and /api/gossip/wrapping-key to the cluster subnet as an additional defence-in-depth measure.