Interoperability matrix#

Requirements: QA-004 (publish tested counterparts and exact versions), QA-006 (distinguish internal tests from conformance and certification).

A tested profile below means that the named counterpart, at the named version, exercised the listed surface in the owning service or SDK test suite. It is not a claim of compatibility with every feature of that counterpart, or with other versions of it.

Conformance claims#

Rules for claims (QA-006, ADR 0020):

• Documentation that describes protocol behavior ("RFC 9449 proofs at the token endpoint", "OpenID Connect discovery") describes what the code implements and the internal tests exercise, not conformance.
• A claim at the second or third level is added here only together with its evidence: suite name and version, test plan, ProudAuth commit or release, and a link to the published results or certificate.
• Certification applies to a deployed product version, not to this source tree. An operator who certifies a deployment holds that certificate; it does not extend to the project or to other deployments.

Tested profiles#

Toolchains and runtimes#

Counterparts#

Everything here is internal testing: the server runs in-process (tests/e2e/harness_test.go) against real PostgreSQL. Service end-to-end tests use the checksum-pinned public Go SDK; the other SDKs execute their controlled counterparts in their independently pinned repositories. The source API versions remain the Go SDK's admin.Version, Node.js SDK_VERSION, Dart sdkVersion and PHP SDK Version::SDK_VERSION and .NET SDK AdminClient.SdkVersion, all 0.2.0.

The Compose smoke test (scripts/smoke-test.sh, CI job image) additionally checks the built container image: liveness, readiness, discovery, JWKS and that the password grant is refused.

Third-party products#

Third-party software is exercised in two ways. For the migration adapters (MIG-002, MIG-018), exports produced by the real products are committed under internal/migrate/testdata/, converted, planned and imported through the import APIs, after which the migrated users sign in with their source passwords. Protocol counterparts run live against ProudAuth built from the same commit: libraries in an end-to-end test, products in a script that starts them in throwaway containers (and in the interop.yml workflow).

A tested profile is one export, or the listed profile, of one version; it is not compatibility with every feature of that product (QA-004). Other releases of the same major version are accepted but untested (migration-adapters.md).

Keycloak 26.8.0 protocol profiles#

scripts/interop-keycloak.sh (make interop-keycloak; weekly and on demand in the interop.yml workflow on ubuntu-24.04) runs four scenarios against Keycloak 26.8.0 and stops at the first failed assertion; a run takes about half a minute once the images are present. Last passing runs: 2026-10-11, seven consecutive runs of the final script on linux/arm64 (Docker Desktop on macOS), one of them under dash (Ubuntu's /bin/sh); the test certificates were also generated with LibreSSL 3.3 in an earlier passing run. The weekly workflow runs it on linux/amd64.

Set-up, all in throwaway containers on one Docker network:

• Keycloak 26.8.0, start-dev: its H2 database, the host name taken from the request, HTTPS only, with a certificate from a test CA the script generates and that CA in --truststore-paths. Realms, clients and identity providers are created through the admin REST API.
• ProudAuth: identity-server, identity-worker and identity-cli built from the same checkout (static Linux binaries in gcr.io/distroless/static-debian12:nonroot) on PostgreSQL 18 (postgres:18, 18.6 at the last run), mode: development with TLS on the public listener (server.tls_cert_file), federation.allow_private_network, federation.ca_file (the test CA), delivery.allow_private_webhooks with SSL_CERT_FILE naming the test CA (back-channel logout), saml.enabled and the development email sink.
• Login UI and browser: the realm's interaction.login_ui_url is served by nobody; the script plays the login UI through the transaction API in browser mode (the pa_tx cookie, X-CSRF-Token, Origin), and plays the browser with curl and one cookie jar per user, submitting the HTML forms it meets (Keycloak's login form and logout confirmation, the auto-submitting SAML forms of both products). Host names resolve to the published ports through curl --resolve, so issuers and entity IDs are the same inside and outside Docker.

What the runs found:

• Defect, fixed: the SAML broker refused every response that repeated an attribute name (duplicate_attribute). Keycloak's default client scope role_list (mapper "role list" with "Single Role Attribute" off) sends one Role element per role, and Keycloak users normally hold roles (default-roles-<realm>), so no such user could sign in through a SAML connection to Keycloak in its default configuration. Repeated names are now one multi-valued attribute; the connection's subject and email attributes must still appear once (saml.md, TestSAMLBroker).
• Keycloak settings that matter: ProudAuth's SAML applications receive responses over HTTP-POST only, so the Keycloak identity provider needs "HTTP-POST binding response"; without it Keycloak asks for HTTP-Redirect and ProudAuth answers saml_unregistered_acs (checked by the script). Keycloak's SP metadata lists an HTTP-Redirect ACS as its default; ProudAuth registers only the HTTP-POST one. ProudAuth's IdP metadata says WantAuthnRequestsSigned="false" because signing is decided per application, so turn on "Want AuthnRequests signed" at Keycloak when the application requires signed requests (the default when its metadata has a certificate).
• Documentation gap, fixed: back-channel logout, webhook and hook deliveries trust the system roots only (there is no delivery CA file); a private CA goes into the system trust store (configuration.md).

Not covered with Keycloak#

• Keycloak in production mode (start, an external database, fixed host names, a reverse proxy) and other Keycloak releases.
• ProudAuth in production mode: the run uses development mode for the email sink and for private-network egress (allow_private_network, allow_private_webhooks); production uses federation.egress_allowlist and delivery.egress_allowlist, which are not exercised.
• OpenID Connect: client_secret_post, client_secret_jwt and private_key_jwt between the products; ES256, PS256 or EdDSA keys; pairwise subjects; refresh tokens and offline_access; PAR, DPoP, JARM, encrypted ID tokens and the claims parameter; prompt, max_age, login_hint or acr_values forwarded by Keycloak; front-channel logout; logout from Keycloak towards ProudAuth when ProudAuth is the relying party (ProudAuth accepts no logout from upstream providers, FED-013).
• SAML: AuthnRequests over HTTP-POST; IdP-initiated SSO; Artifact and SOAP (not supported); encrypted assertions from Keycloak (the broker refuses them); unsigned requests; emailAddress, transient and unspecified NameIDs; ForceAuthn, IsPassive and RequestedAuthnContext; logout initiated by ProudAuth (not supported) or by Keycloak as identity provider; a signing-key rollover while Keycloak holds ProudAuth's metadata.
• Real browsers (cookies, SameSite, Keycloak's scripts), load, and clock skew between the hosts.

Untested claims#

These are described in the documentation, or follow from the standards ProudAuth implements, but no test in this repository exercises them against the real counterpart. Treat them as expectations to verify in your environment:

• Third-party relying parties and gateways (for example openid-client, Spring Security, oauth2-proxy, Envoy): expected to work through standard discovery, PKCE and JWKS; not run. Only go-oidc with golang.org/x/oauth2 and Keycloak 26.8.0 (identity brokering) have run, in the profiles listed under Third-party products.
• Real upstream identity providers (Google, Microsoft Entra ID, Okta, GitHub, …). The google and microsoft adapters encode those providers' documented issuers, tenant claims and email semantics; only test doubles have signed users in, and only the configuration of these two adapters is tested. Upstream end-session endpoints of these providers are not tested. The only real provider that has signed users in is Keycloak 26.8.0, through the generic oidc adapter and a SAML connection (profiles).
• SCIM clients of real directories (Okta, Microsoft Entra ID, Google Workspace, HR systems): the request shapes they are known to send are covered by TestSCIMProvisioning; no real directory has provisioned against ProudAuth and no SCIM conformance suite has been run (scim-provisioning.md).
• SAML service providers and identity providers other than Keycloak 26.8.0 (for example Shibboleth, SimpleSAMLphp, Okta, Microsoft Entra ID, ADFS, SaaS applications): both SAML roles have been exercised against the test SP and IdP in this repository and against Keycloak 26.8.0 (profiles), and against nothing else. SAML-010 asks for tests against multiple independent implementations; Keycloak is one, and no SAML conformance suite has been run (saml.md).
• Real directories (Microsoft Active Directory, OpenLDAP, 389 Directory Server, other LDAP servers): LDAP sign-in, synchronization, failover and write-back have run only against the in-process ldaptest server (directory.md).
• Downstream SCIM services for outbound provisioning (SaaS applications, directories) other than ZITADEL v4.16.3: only the in-process SCIM double and ZITADEL, in the profile listed above, have received pushes; no SCIM conformance suite has been run (outbound-provisioning.md).
• Challenge providers. The verification request follows the siteverify interface several bot-detection services use; only a test double answers it.
• KMS and HSM command-line tools (AWS KMS, Google Cloud KMS, HashiCorp Vault transit, PKCS#11 tools): the kms: contract is tested with a stand-in command only (keys.md).
• OpenTelemetry collectors and tracing back ends: only the OTLP/HTTP JSON payload shape is tested.
• Real browsers (cookies, SameSite and CORS behavior are exercised only through Go HTTP clients), and custom domains behind a real reverse proxy and TLS certificates.
• Hardware or platform authenticators, and attestation formats other than none and the test double's packed attestation; a real FIDO Alliance Metadata Service BLOB (tests load a BLOB signed under a test root); related origins in browsers with WebAuthn Level 3 support (passkey-trust.md).
• The check-session iframe in real browsers, including how third-party cookie blocking and partitioning affect it (oauth-oidc-profile.md).
• Real shared-signals transmitters and receivers (CAEP and RISC implementations of identity providers, SaaS platforms or security products): only the test servers in this repository have exchanged events, and no SSF interoperability suite has been run (shared-signals.md).
• Container registries (Distribution, Harbor, cloud registries) and the Docker client: the token endpoint was driven directly by the test harness (container-registry.md).
• Workload identity issuers (GitHub Actions, Kubernetes service-account token issuers, SPIFFE implementations such as SPIRE): the jwt-bearer grant is tested only with tokens the test suite signs in their shapes, with key sets served locally (workload-federation.md).
• Mutual TLS behind real proxies and with real certificate authorities (nginx or Envoy forwarding client certificates, smart cards for X.509 sign-in): tests use in-process TLS and certificates generated by the test suite (mutual-tls.md).
• FAPI 2.0. The fapi2 client profile is tested by TestFAPI2Profile only. It is not certified by the OpenID Foundation and no FAPI conformance suite has been run (oauth-oidc-profile.md).
• Dynamic registration, JARM, encrypted responses and front-channel logout with third-party clients (relying-party libraries, OpenID Connect conformance tools): exercised only by the test harness's own clients (TestDynamicClientRegistration, TestJARM, TestEncryptedResponses, TestFrontChannelLogout); front-channel frames were not run in a real browser.
• External policy engines (Open Policy Agent and others): the engine contract is tested against a local HTTP double (TestExternalPolicyEngine), not against a real engine.
• Real SMTP servers and real SMS gateways (end-to-end tests use the development sinks; the webhook SMS adapter is unit-tested against a local HTTP server in internal/notification/sms_test.go).
• Other runtime versions: PostgreSQL other than 17 and 18, Node.js other than 22 (including the declared minimum 20.10), Dart other than 3.13.3 (including the declared minimum 3.4), PHP 8.3 and 8.4, Go releases other than the 1.27 patch release CI used (including the go.mod minimum 1.27.1).
• Mixed-version deployments with two real binaries. TEST-061 is covered at the storage layer (TestMixedVersionWindow simulates migrations from a newer release).
• Operation in a network-isolated container. TEST-072 is covered in-process (TestOfflineOperation blocks non-loopback dialing and DNS).
• Multi-node behavior (several servers and workers against one database): the suite runs one in-process server; see benchmarks.md.

Contributions that add interoperability tests against named third-party versions are welcome; record the exact versions in Tested profiles when they land.