Core concepts
Learn the actors, data boundaries, identity model, and vocabulary behind an Unbound sign-in.
Unbound connects an app to an external sign-in provider through a focused authorization-code flow. These concepts explain why each redirect, scope, and validation step exists.
How Unbound works
Follow the complete flow across the browser, app, Unbound, and provider.
Stateless design
See where browser state, authorization codes, tokens, and limited records live.
Identity, scopes, and claims
Connect user approval to the pairwise identity and fields an app receives.
Security and privacy
Review trust boundaries and the responsibilities that remain with the app.
Glossary
| Term | Meaning |
|---|---|
| App | The application requesting authentication and approved identity data. |
| App origin | The HTTPS origin used to identify the public client, bind the callback, and scope the pairwise identity. |
| Provider | An external sign-in provider—currently Google, GitHub, or Discord when configured—that authenticates the user to Unbound. |
| Authorization code | A short-lived encrypted value returned to the app callback and exchanged for a token. |
| Token | A short-lived signed JWT bearer token issued after a successful code exchange. |
| Scope | A requested category of access: currently openid, profile, or email. |
| Pairwise subject | The app-scoped Unbound user ID in the token’s sub claim. Different app origins receive different values. |
Unbound exposes OIDC-style discovery, JWKS, authorization, token, and userinfo endpoints. This describes the current implementation, not full OpenID Connect certification or generic client compatibility.