Authorization, programmable
Named scenarios where Hub is the right OAuth2 / OIDC layer.
Five scenarios — each a concrete OAuth2 / OIDC deployment Hub is built to serve.
Customer: A SaaS vendor whose enterprise customers bring their own IdPs (Okta, Azure AD, Google Workspace, SAML).
Shape: Each customer tenant maps to a federation member. Hub routes authorize requests by tenant; user logs in at their own IdP; Hub returns a standard OAuth2 token to your app.
Customer: A SaaS vendor wanting tenant admins to manage their users' access policies.
Shape: Your app uses Hub's OAuth2 surface; tenant-specific policies live in your app. Hub is pure protocol — it doesn't model permissions.
Customer: A regulated customer (bank, insurer, healthcare) needing eIDAS 2.0 support alongside traditional SSO.
Shape: Hub delegates to the eIDAS Verifier for EUDIW-based authentication; the returned ID token carries verified claims. Indistinguishable from a normal OIDC login to your app.
Customer: A consumer-facing app wanting Google / Apple / GitHub login alongside email/password.
Shape: Federation members for each social provider; Hub brokers the OAuth2 to your app. Users see a consistent sign-in page with all providers.
Customer: An enterprise with internal employees (Azure AD) and external contractors (different IdPs).
Shape: Hub maps both populations behind a single OAuth2 endpoint. Your app sees normalised tokens; the populations never interact.
Request access and we'll have your first federation member connected in under a day.