OAuth 2.0 access management
Secure your APIs with access tokens
The Connect2id server is a fully fledged OAuth 2.0 server, capable of securing web APIs and other resources with highly customisable access tokens. Applications can choose from a rich variety of standard OAuth 2.0 grants to fulfil their needs:
For web applications as well as mobile / native clients
Resource owner password
For trusted 1st party mobile / native clients
For clients that act on their own behalf
For trusted clients in external security domains
SAML 2.0 assertion
For SAML clients that need to obtain OAuth tokens
Token exchange ✲
For delegation and impersonation scenarios
Device code ✲
For input constrained devices such as smart TVs or printers
For back-channel authentication and consent on a mobile device
✝ Implicit is deprecated in OAuth 2.1, use authorisation code instead
✲ On the Connect2id server roadmap
Bring your own policies
If your are an architect you enjoy plenty of freedom with the Connect2id server:
- Apply special rules and security policies to each OAuth 2.0 grant. Their logic can be implemented in any programming language, and is applied via simple Connect2id APIs (web or plugin).
- Authorisations can be short-lived (transient) or long-lived (persisted). The latter enable end-user consent to be remembered across token requests and login sessions.
- The issued access tokens can be stateless (a JWT) for optimal performance, or identifier-based for maximum security, guaranteed single-use and revocation with immediate effect.
- Token scopes can be assigned implicitly.
- The lifetime of the issued ID, access and refresh tokens can be controlled for each individual client and end-user.
- Tokens can carry additional data and claims.
Version 4 of the Connect2id server added support for special scenarios:
- Impersonation — enables a privileged user to log into a client application under a different identity. May also extend to accessing protected protected resources (web APIs) as the impersonated identity and using their permissions.
- Delegation — enables one user to act on behalf of another.
The Connect2id server provides standard as well as own endpoints to manage the entire life cycle of a token:
- Token issue
- Token introspection
- Updating the associated scope and other details (for long-lived authorisations / refresh tokens)
- Token revocation
- Query long-lived authorisations per client or end-user
Access token profiles
Connect2id server deployments can use one of the ready profiles for JWT-encoded access tokens, such as the common profile developed by OAuth 2.0 working group, or define their own custom JSON / claims structure.
The token introspection responses can be similarly customised.
Sender constrained tokens
The issued access tokens (and refresh tokens for public clients) can be sender-constrained, to prevent unauthorised use in case of an accidental or malicious token leak.
mTLS / client X.509 certificate bound tokens -- Intended for web and mobile applications, such as those that must comply with the FAPI (Financial-grade API) security profile.
DPoP tokens -- Intended for Single Page Applications (SPAs), the tokens are bound to a private RSA or EC key, generated and managed via the browser WebCrypto API, with disabled extraction of the private key parameters.
Applications that are distributed across data centres can benefit from the use of stateless access and refresh tokens. Performance and latency can be boosted by switching to the JWS EdDSA algorithm to sign the issued access tokens. This new algorithm allows for compact signatures, which need only a fraction of a millisecond to generate or verify.