Authorisation and access

Secure APIs with access tokens

The Connect2id server is a fully fledged OAuth 2.0 & OAuth 2.1 server, capable of securing APIs and other resources with highly customisable access tokens. Client applications have a choice of nine standard OAuth grants to obtain tokens:

Authorisation code

For web applications as well as mobile / native clients

Implicit ^✝

For browser-based JavaScript applications

Resource owner password

For trusted 1^st party mobile / native clients

Client credentials

For clients that act on their own behalf

JWT assertion

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

CIBA ^✲

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

The Connect2id server gives architects the freedom and the means to address wide-ranging application and security requirements.

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 a simple Connect2id API (web or SPI plugin).
Authorisations can be short-lived (transient) or long-lived (persisted). The former are ideal for transactions, the latter enable 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 to guarantee payload confidentiality, single-use and revocation with immediate effect.
Token scopes can be assigned implicitly.
The lifetime of issued ID, access and refresh tokens can be controlled for each individual client and user.
Tokens can carry additional data and claims.

Special scenarios

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.

Token management

The Connect2id server provides standard as well as own feature endpoints to manage the life cycle of a token:

Token issue
Token introspection
Updating the associated scope and other parameters (for long-lived authorisations)
Token revocation
Query long-lived authorisations for a client or user

Access token profiles

Deployments can use one of the available profiles for JWT-encoded access tokens, such as the RFC 9068 profile developed by the OAuth working group, or define their own custom JSON / claims structure.

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.

Distributed applications

Applications which are distributed across data centres can benefit from stateless access and refresh tokens. Performance and latency can be further boosted by switching to the JWS EdDSA algorithm to sign the access tokens, for compact signatures which need only a fraction of a millisecond to generate or verify.