Authorization, programmable
Compliance
RFC conformance, OIDC Core, eIDAS 2.0 mapping, and the 'no user data in the hub' posture.
Hub implements the OAuth2 + OIDC family of RFCs. Every claim is backed by a conformance test in CI.
RFCs + specs implemented
| Reference | Title | What it covers |
|---|---|---|
| RFC 6749 | OAuth 2.0 Authorization Framework | Authorization code grant, token endpoint, client authentication — the core. |
| RFC 6750 | Bearer Token Usage | Access tokens presented as Bearer tokens in Authorization headers. |
| RFC 7009 | Token Revocation | Clients can revoke refresh tokens on sign-out; Hub revokes the whole family. |
| RFC 7636 | PKCE | Protects public clients from authorization-code interception. |
| RFC 9126 | Pushed Authorization Requests (PAR) | Confidential clients push the authorization request to the back channel. |
| OIDC Core 1.0 | OpenID Connect | The identity layer on top of OAuth2 — ID tokens, userinfo, discovery. |
eIDAS 2.0 mapping
Hub is not itself an eIDAS component, but it's the OAuth2 surface a relying party usually exposes. For EUDIW-based authentication, Hub delegates to the eIDAS Verifier and surfaces verified claims via ID token — a standard OIDC shape your app already handles.
GDPR — no user data in the hub
Hub is a pure identity broker. It holds no user profiles, no credentials, no organisation data. All identity lives in the federation members. A compromised Hub leaks session metadata and token signatures — not user PII.
NIS2
ES256 signatures via Vault Transit. TLS 1.3 everywhere. Redis + Postgres for operational state (no user data). Horizontal scaling, stateless request path.
Also on Hub
Ready to wire up OAuth?
Request access and we'll have your first federation member connected in under a day.