Introduction

Ahdapa is an OAuth 2.0 and OpenID Connect authorization server built for FreeIPA Kerberos environments. It bridges your existing Kerberos identity infrastructure to the OAuth 2.0 / OIDC ecosystem used by modern applications — issuing cryptographically signed JWT tokens to users and services that are already authenticated via Kerberos, with no separate user database and no external identity broker required.

It is the token-issuance counterpart to Akāmu, the ACME certificate authority: where Akāmu issues X.509 certificates, Ahdapa issues OAuth 2.0 bearer tokens.

Key capabilities

• Zero-click SSO for Kerberos domain members via SPNEGO. Clients that are not on the domain can authenticate with a password form, a passkey (WebAuthn), or a federated external IdP.

• Full OAuth 2.0 and OpenID Connect coverage — authorization code + PKCE, client credentials, device flow, token exchange, refresh tokens, DPoP, PAR, mutual-TLS client authentication, and Kerberos machine client authentication (kerberos_client_auth). See Standards for the complete RFC list.

• Machine-readable directory API (/api/identity/) for SSSD and other system-level clients. Bearer-token-gated user and group lookups with a two-phase search protocol compatible with SSSD’s ahdapa_lookup(). Enrolled machines obtain tokens via kerberos_client_auth (no per-machine secret) and use them to resolve users and group memberships on demand.

• Built-in horizontal scaling via a gossip protocol — no external coordinator or shared database required. Signing keys, client registry, and session revocations replicate automatically across all nodes.

• Post-quantum ready — JWT signing with ML-DSA (FIPS 204 / Dilithium); gossip traffic encrypted with ML-KEM-768 (FIPS 203 / Kyber). Classical EC and EdDSA algorithms are supported alongside PQC for mixed-client environments.

• FreeIPA-native — discovers external IdP registrations and per-user authentication constraints directly from FreeIPA LDAP at startup, without duplicating IdP configuration into a local file.

• Access control policies (HBAC) modelled on FreeIPA HBAC rules: define which users may obtain tokens for which clients, from which source networks, with what required authentication strength.

• SPIFFE Workload API — ahdapa can act as a trust domain authority and Workload API server for SPIFFE. When [spiffe] trust_domain is set, ahdapa issues X.509-SVIDs and JWT-SVIDs to local workloads via a Unix domain socket gRPC server, publishes the trust bundle at /.well-known/spiffe-bundle, and bridges SPIFFE identity to OAuth2 by recognising workloads that present their X.509-SVID in an mTLS connection.

• ACME Token Authority (RFC 9447) — when [gssapi] is configured, ahdapa acts as an RFC 9447 Token Authority for ACME tkauth-01 challenges. Clients authenticated via Kerberos SPNEGO obtain a signed authority token JWT whose atc.tkvalue carries base64url-encoded EnhancedJWTClaimConstraints (RFC 9118) with mustInclude: ["sub"] and permittedValues binding sub to the Kerberos principal name and iss to the server’s issuer URL. For host and service principals, the server additionally looks up IPA-managed FQDNs via LDAP and adds a dns entry to permittedValues; user principals receive an identity-only token with no dns constraint. This is a Kerberos-identity binding — not the telephony tnauthlist profile. The endpoint is advertised in the AS discovery document as token_authority_endpoint.

What Ahdapa is not

• Not a reverse proxy or API gateway. Ahdapa can terminate TLS natively (see [tls] configuration) or run behind a TLS-terminating load balancer (nginx, HAProxy, Caddy).

• Not a Kerberos KDC or FreeIPA administration interface. It reads from FreeIPA LDAP and acquires service tickets; it does not create or manage Kerberos principals or directory entries.

• Not a general-purpose ACME certificate authority. Use Akāmu for X.509 certificate issuance within the same Kerberos realm.

• Not a user identity store. Users are authenticated against Kerberos, PAM, or FreeIPA LDAP. Ahdapa does not maintain its own user registry.

Standards coverage

Ahdapa implements OAuth 2.0 (RFC 6749), OpenID Connect Core 1.0, and 20+ related specifications including DPoP, PAR, mTLS client authentication, token exchange, device flow, and the RFC 9447 ACME Token Authority protocol. See Standards for the complete list with implementation scope and known limitations.

Where to go next