Skip to content
Connect2id

Datasheet

1. Server endpoints

The Connect2id server supports the standard OAuth 2.0 / OpenID Connect endpoints for single sign-on (SSO), authorisation and identity provision. It also provides a number of powerful RESTful and native interfaces for integration of end-user, monitoring and administration interfaces / tools.

Standard OAuth 2.0 / OpenID Connect endpoints

  • Provider metadata – Advertises the standard OAuth 2.0 / OpenID Connect endpoint URLs, identity provider capabilities and supported security (JOSE + JWT) algorithms.

  • Provider JWK set – Publishes the provider’s public JSON Web Key (JWK) set and certificate chain, required by client applications to verify ID tokens and other issued objects.

  • Client registration – Registers client applications with the Connect2id server, so they can login end-users and request ID and / or access tokens. The endpoint can be operated in a public (open registration) or private mode. Supports the optional client read, update and delete operations.

  • Authorisation – The standard OAuth 2.0 endpoint for receiving OpenID Connect authentication (login) requests from client applications.

  • Token – The standard OAuth 2.0 endpoint for exchanging authorisation grants for an access, refresh and / or ID token. Supports all standard OAuth 2.0 grants: authorisation codes, refresh token, resource owner password, client credentials, JWT bearer assertions and SAML 2.0 bearer assertions.

  • Token introspection – Standard OAuth 2.0 endpoint for resource servers to inspect issued access tokens.

  • Token revocation – Standard OAuth 2.0 endpoint for client applications to revoke issued access and refresh tokens.

  • UserInfo – Protected resource for releasing consented claims (name, contact and other details) about the subject (end-user).

Integration & plugin interfaces

  • Authorisation session – Provides login page (UI) integration, plug-in of arbitrary end-user authentication methods and custom business / authorisation logic for setting the claims and scopes of the issued ID and access tokens.

  • Direct authorisation – Facilitates direct issue of ID, access and refresh tokens, without going through the standard OAuth grant mechanisms. Can be used to proxy and federate external identity providers, including legacy systems.

  • Authorisation store – Enables query, update and revocation of issued OAuth 2.0 / OpenID Connect authorisations and the associated access and refresh tokens.

  • Subject session – Enables query, access and management of the end-users’ SSO sessions with the Connect2id server.

  • Monitoring – Provides access to over 100 server usage and performance metrics and execution of health-checks.

  • Claims source – Integrates OpenID Connect claims sources, such as LDAP directories, SQL databases and HR management systems.

  • Password grant handler –n Enables plug-in of authorisation logic for handling OAuth 2.0 resource owner password credentials grants.

  • Client credentials grant handler – Enables plug-in of authorisation logic for handling client OAuth 2.0 credentials grants.

  • JWT bearer assertion grant handler – Enables plug-in of authorisation logic for handling client-issued and third-party issued (token service) JWT bearer grants.

  • SAML 2.0 bearer assertion grant handler – Enables plug-in of authorisation logic for handling client-issued and third-party issued (token service) SAML 2.0 bearer assertions grants.

2. Supported OAuth 2.0 / OpenID Connect response types

The Connect2id server supports all standard OpenID Connect response types. The server can be configured to accept only a subset of these, either for the entire provider or on a per client basis. The token response is generally not supported as it falls outside the scope of OpenID Connect; clients should use token id_token instead.

  • code – Used to request an ID token and access token at the Token endpoint.

  • id_token – Used to request an ID token (implicit grant).

  • token id_token – Used to request an ID token and access token (implicit grant).

  • code id_token – Used to request an ID token with the authorisation response as well as an ID token and access token at the Token endpoint.

  • code id_token token – Used to request an ID and access token with the authorisation response and at the Token endpoint.

3. Supported OAuth 2.0 response modes

The Connect2id server supports all standardised OAuth 2.0 response modes:

  • query – Returns the response in the redirection URI query string.

  • fragment – Returns the response in the redirection URI fragment.

  • form_post – Returns the response via a form post to the redirection URI.

Custom response modes, such as based on a CORS Ajax request or on window.postMessage, can also be implemented via add-on.

4. Supported OAuth 2.0 grant types

The Connect2id server supports all core OAuth 2.0 grant types. The server can be configured to accept only a subset of these, either for the entire provider or on a per client basis.

  • authorization_code – Used in the authorisation code flow.

  • implicit – Used in the implicit flow.

  • refresh_token – Used for long-lived authorisations.

  • password – Used for highly-trusted or privileged client applications, when the other safer grant types (e.g. authorisation_code) are not available.

  • client_credentials – Used by clients acting on their own behalf (the client is also the resource owner).

The following bearer assertions are also supported:

Additional custom grants can be implemented via the universal endpoint for direct authorisation.

5. Supported OAuth client types

Confidential as well as public clients are supported:

  • Confidential clients – can maintain the confidentiality of their credentials, typically implemented on a secure server

  • Public clients – cannot maintain the confidentiality of their credentials, typically clients on end-user devices

6. Proof key for code exchange (PKCE)

The Proof Key for Code Exchange (PKCE) protocol (RFC 7663) is supported to protect against authorisation code interception attacks on public OAuth clients.

The following code verifier transforms are supported:

  • S256 – SHA-256 (mandatory to implement)
  • plain – for legacy clients

7. Supported subject identifier types

The Connect2id server supports public subject identifiers. Pairwise subject identifiers are on the roadmap.

  • public – Public subject identifier

8. OpenID Connect authentication request parameters

The Connect2id server supports the mandatory to implement authentication request parameters for all OpenID Connect providers. Support for the optional request objects, passed directly or by URI reference, is on the roadmap.

  • Supported OAuth 2.0 parameters: response_type, response_mode, client_id, scope, redirect_uri, state, code_challenge, code_challenge_method

  • Supported OpenID Connect parameters: nonce, display, prompt, max_age, ui_locales, claims_locales, id_token_hint, login_hint, acr_values, claims

  • Unsupported OpenID Connect parameters: registration, request, request_uri

9. Supported client authentication methods

The Connect2id server supports all standard authentication methods for OAuth 2.0 clients.

  • client_secret_basic – Basic HTTP authentication with client secret
  • client_secret_post – Basic HTTP authentication with client secret
  • client_secret_jwt – JWT assertion authentication with client secret
  • private_key_jwt – JWT assertion authentication with a private RSA or EC key that belongs to the client

10. Supported ID token algorithms

The Connect2id server supports JSON Web Signature (JWS) protected ID tokens. Support for encrypted ID tokens is on the roadmap.

  • RS256, RS384, RS512, PS256, PS384, PS512 The ID token is signed with the provider’s RSA JWK.

  • HS256, HS384, HS512 The ID token is integrity protected with the provider-issued client secret.

11. Supported claim types

The Connect2id server issues normal claims. Aggregated and distributes claims, asserted by a claims provider other than the OpenID provider, will be supported in a future release.

  • normal Claims directly asserted by the provider.

11. Offline access

The Connect2id server supports authorisations bound to a subject’s session as well as offline access by means of long-lived OAuth 2.0 refresh tokens.

13. Subject (end-user) authentication

Traditional password-based authentication of end-users as well as stronger two-factor methods are supported.

Upon successful login a client application may be informed of the employed authentication strength and methods, communicated through the standard acr and amr ID token claims.

The Connect2id server supports integration of arbitrary authentication methods. Microsoft Active Directory / LDAP is supported out of the box, through an LdapAuth service.

14. Claims data sources

The Connect2id server supports aggregation of claims (standard UserInfo and others), with optional language tags, from one or more data sources.

Sourcing of end-user claims from Microsoft Active Directory / LDAP is supported out of the box. A generic interface is available for connecting other claims sources, such as relational or NoSQL database, SCIM web services and HR systems.

15. Access token types

The Connect2id server supports both types of OAuth 2.0 access tokens:

  • Self-contained: The access token is encoded as a secure JSON Web Token (JWT) containing all necessary authorisation details for the resource server. The JWT has an RSA signature, which the resource server can verify with the issuer’s public key. The standard RS256, RS384, RS512, PS256, PS384 and PS512 JWS signature algorithm are supported. The JWT may also optionally be encrypted with AES for confidentiality. The following claims (fields) can be included in the JWT: subject (end-user ID), client ID, issuer, audience, scope, token issue time, token expiration time, consented claims, optional custom data. The self-contained token can also be inspected by a web call to the Connect2id token introspection endpoints.

  • Identifier-based: The access token is represented by a secure random identifier. The corresponding authorisation is looked up by a web call to the Connect2id token introspection endpoints. Identifier-based tokens are intended for minimal clients that cannot verify JWT signatures, or for applications which security requires revocation to have an immediate effect.

16. Impersonation

Impersonation use cases are supported:

  • Issue of impersonated ID tokens to enable privileged users to log into a client under a different identity.

  • Issue of impersonated access and refresh tokens to enable privileged users to access protected resources under a different identity.

The Connect2id server provides a web API for querying, updating and revoking impersonated tokens and authorisations.

17. High-availability and scaling

The Connect2id server can be run in two modes.

  • Single server – The Connect2id server runs in a single server instance.

  • Cluster – The Connect2id server runs in a cluster configuration for high-availability and load-balancing. Server nodes can be added or removed dynamically. Supported clustering modes:

    • Replication – for relatively low loads and medium sized user bases.
    • Distribution – for relatively high loads and large user bases.

18. Metrics and monitoring

The Connect2id server proves a RESTful endpoint for accessing over 100 different metrics to monitor usage and performance.

The collected metrics can also be reported via JMX or Graphite.

Questions or comments?

Get in touch with Connect2id support.