Authorization, programmable
OAuth2 authorization, without running a user database.
Hub is a stateless OAuth2 / OIDC authorization server that delegates authentication to your federation members (Okta, Azure AD, SAML IdPs, or your own). Tokens are signed via HashiCorp Vault Transit — your service never touches the private keys.
What Hub does
Hub accepts OAuth2 clients, determines which federation member each client should authenticate against, delegates authentication to that IdP, and issues signed access and refresh tokens back to the client. Signing keys are managed by Vault Transit — Hub has no direct access to them, so a compromised Hub process cannot forge tokens. Refresh tokens are tracked in families so that a stolen token is detected and the entire lineage is revoked.
Flow
How a login flows
- Step 1
Client redirects user to GET /oauth2/authorize (optionally via PAR for confidential clients).
- Step 2
Hub determines the federation member the client uses and redirects the user there.
- Step 3
The external IdP authenticates the user and redirects back with a code.
- Step 4
Hub exchanges the code, sets a short-lived FED_TOKEN cookie, and redirects back to /oauth2/authorize.
- Step 5
Hub validates the FED_TOKEN, signs tokens via Vault Transit, and returns the authorization code to the client.
Standards
Standards Hub implements
OAuth 2.0 (RFC 6749)
Authorization code grant and token endpoint, per the core RFC.
OpenID Connect 1.0
User authentication, ID tokens, and discovery — the identity layer on top of OAuth2.
PAR (RFC 9126)
Pushed Authorization Requests for confidential clients that need request-object integrity.
Refresh token rotation
Token family tracking detects stolen refresh tokens and revokes the whole lineage.
Compliance
Stateless by design
Hub holds no authentication session database. All state is either in Vault-signed tokens or in short-lived, single-use cookies. Compromising the Hub process does not compromise the user population.
- No central session store — all state in Vault-signed tokens or short-lived cookies
- Refresh token replay protection via token families
- Vault Transit for all signing keys — Hub has no direct key access
- OIDC federation delegates passwords to your IdPs — Hub never stores credentials
Integration
Register a client, redirect your users, you're done
Register your OAuth2 client (client_id, redirect_uri, allowed scopes). Configure which federation member(s) it uses. Point your app's login button at GET /oauth2/authorize. Users land at the IdP, authenticate, and come back with a signed access token.
- OAuth 2.0 / OIDC compliant — any existing OIDC SDK works out of the box
- PAR supported for confidential clients and request-object integrity
- Configurable per-client refresh token posture (rotate strictly, or reuse within a family)
FAQ
Frequently asked
- Can I use Hub without an external IdP?
- Not yet. Hub is built on the premise of delegating to federation members. If you want a username/password OAuth2 server, implement a custom federation member that handles local users. Hub itself speaks only OAuth2 federation protocol.
- How do you prevent refresh token theft?
- Tokens are issued in a family. When a stolen refresh token is used, Hub detects the family mismatch and revokes the entire lineage, making all tokens in that family invalid. You can also configure strict rotation (new refresh token on every use) per client.
- Where are the private signing keys?
- HashiCorp Vault Transit. Hub never holds them directly. Every JWT signature goes through Vault, so a compromised Hub process cannot forge tokens. The trade-off is a Vault round-trip per token — usually acceptable for interactive flows.
Ready to wire up OAuth?
Request access and we'll have your first federation member connected in under a day.