Skip to content
Connect2id

Authorisation and access

Secure your APIs with access tokens

The Connect2id server is a fully fledged OAuth 2.0 & OAuth 2.1 server, capable of securing web APIs and other resources with highly customisable access tokens. Applications can utilise a variety of 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 1st 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

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.

Advanced 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 endpoints to manage the entire life cycle of a token:

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.

Distributed applications

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.