Datasheet
1. OpenID certified provider
The Connect2id server has obtained certification from the OpenID foundation for all standard OpenID provider profiles:
- Basic
- Implicit
- Hybrid
- Configuration
- Dynamic
2. Identity and security profiles
Supported domain-specific OAuth 2.0 and OpenID Connect profiles:
Open banking:
- Financial API — Part 1: Read Only API Security Profile
- Financial API — Part 2: Read & Write API Security Profile
Health care:
- HEART profile for OAuth 2.0
- HEART profile for OpenID Connect
- HEART profile for Fast Healthcare Interoperability Resources (FHIR) OAuth 2.0 scopes
Government / eID:
- International Government Assurance Profile (iGov) for OAuth 2.0
- International Government Assurance Profile (iGov) for OpenID Connect 1.0
3. Server endpoints
The Connect2id server implements all standard OAuth 2.0 / OpenID Connect endpoints for single sign-on (SSO), identity provision and issuing OAuth tokens. It also comes with a number of powerful RESTful and native interfaces for integrating 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 – Receives OpenID authentication requests and OAuth 2.0 authorisation requests from registered clients.
-
Token – Exchanges a valid OAuth 2.0 grant for an access, refresh and / or ID token. Supported grant types: authorisation codes, refresh token, resource owner password, client credentials, JWT bearer assertion and SAML 2.0 bearer assertion.
-
Token introspection – Allows resource servers to inspect issued access tokens. Can optionally return the introspection responses a signed JWT.
-
Token revocation – Allows client applications to revoke issued access and refresh tokens.
-
UserInfo – Releases consented claims (name, contact and other details) about the subject (end-user) to authorised clients.
-
Check session – Handles window.postMessage polling for changes to the end-user authentication status with the OpenID Provider after the client has obtained an ID token.
-
End session – Receives end-session notifications and logout requests from clients.
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.
-
Logout session – Provides logout page integration and end-session request handling.
-
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 – 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.
-
Access token encoding and introspection – Enables plug-in of alternative access token codecs, shaping of token introspection responses.
4. 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; OAuth 2.0 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.
5. 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.
6. 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:
-
JWT Bearer – Using a signed JSON Web Token (JWT) as a grant.
-
SAML 2.0 Bearer – Using a SAML 2.0 assertion as a grant.
Additional custom grants can be implemented via the universal endpoint for direct authorisation.
7. 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
8. 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
9. Supported subject identifier types
The Connect2id server supports the following subject identifier types:
- public – Public subject identifier
- pairwise – Pairwise subject identifier (using SIV AES deterministic encryption)
10. OpenID Connect authentication request parameters
The Connect2id server supports all mandatory and optional OpenID authentication request parameters:
-
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, request, request_uri
11. Supported client authentication methods
The Connect2id server supports all standardised authentication methods for OAuth 2.0 clients plus the recently developed Mutual TLS Profile:
- client_secret_basic – Basic authentication with the client secret passed in the Authorization header.
- client_secret_post – Basic authentication with the client secret passed in the request body as form parameters.
- client_secret_jwt – JWT authentication using the client secret as shared HMAC key
- private_key_jwt – JWT authentication using public RSA or EC cryptography
- self_signed_tls_client_auth – Self-signed client X.509 certificate authentication
12. Supported ID token algorithms
The Connect2id server supports all standard JSON Web Algorithms for securing issued ID tokens by means of a digital signature, HMAC and optional additional encryption.
-
RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384, ES512 – The ID token is signed with a provider’s private RSA or EC key.
-
HS256, HS384, HS512 – The ID token is HMAC SHA protected with a key derived from the client secret.
-
RSA1_5, RSA-OAEP, RSA-OAEP-256, ECDH-ES, ECDH-ES+A128KW, ECDH-ES+A192KW, ECDH-ES+A256KW – The ID token is additionally encrypted with a client’s public RSA or EC key.
-
dir, A128KW, A192KW, A256KW, A128GCMKW, A192GCMKW, A256GCMKW – The ID token is additionally encrypted with an AES key derived from the client secret.
-
none – The ID token is unsecured.
13. Supported UserInfo algorithms
The Connect2id server supports all standard JSON Web Algorithms for securing UserInfo JWT responses by means of a digital signature, HMAC and optional additional encryption.
-
RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384, ES512 – The UserInfo JWT is signed with a provider’s private RSA or EC key.
-
HS256, HS384, HS512 – The UserInfo JWT is HMAC SHA protected with a key derived from the client secret.
-
RSA1_5, RSA-OAEP, RSA-OAEP-256, ECDH-ES, ECDH-ES+A128KW, ECDH-ES+A192KW, ECDH-ES+A256KW – The UserInfo JWT is additionally encrypted with a client’s public RSA or EC key.
-
dir, A128KW, A192KW, A256KW, A128GCMKW, A192GCMKW, A256GCMKW – The UserInfo JWT is additionally encrypted with an AES key derived from the client secret.
14. Supported request object algorithms
The Connect2id server supports the following algorithms for securing request objects
-
RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384, ES512 – The request object JWT is signed with a clients’s private RSA or EC key.
-
HS256, HS384, HS512 – The request object JWT is HMAC SHA protected with a key derived from the client secret.
-
none – The request object JWT is unsecured.
15. Supported claim types
The Connect2id server supports all OpenID claim types:
-
normal – Claims directly asserted by the provider.
-
aggregated – Claims sourced from an external provider, made available as a signed JWT.
-
distributed – Claims which can be obtained from the endpoint of an external provider using a supplied bearer access token.
16. 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.
17. Subject (end-user) authentication
Password-based authentication of end-users as well as stronger multi-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.
18. 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.
19. Access tokens
The Connect2id server supports issue of self-contained and identifier-based access tokens (see RFC 6749, section 1.4) of type bearer, optionally bound to a client certificate for greater security:
-
Self-contained: The access token is encoded as a JSON Web Token (JWT). The JWT encapsulates all necessary authorisation details for relying resource servers to process requests from clients.
The JWT has an RSA signature, to be validated with the Connect2id server’s public key. All standard RSA signature algorithms are supported: RS256, RS384, RS512, PS256, PS384 and PS512. The JWT can optionally be encrypted with an AES key shared with the resource server(s) for confidentiality.
The following JWT claims (fields) are supported:
Claim Type Description iss string Issuer URL sub string Subject (end-user) ID act object Actor, in impersonation and delegation scenarios cid string Client ID aud string array Audience. Can be used to explicitly denote the protected resources for which the access token is intended. scp string array Token scope iat integer Issue time (seconds since Unix epoch). The token must not be accepted as valid before that time. exp integer Expiration time (seconds since Unix epoch). The token must not be accepted as valid after that time. jti string Secure random JWT identifier. clm string array Names of any consented OpenID claims cll string array Preferred claims locales uip object Preset OpenID claims for release at the UserInfo endpoint cnf.x5t#S256 object Confirmation of client X.509 certificate dat object Optional data An SPI is provided for plugging alternative JWT claim encodings.
Self-contained token can also be inspected by a call to the Connect2id token introspection endpoint.
-
Identifier-based: The access token is represented by a secure random 128 bit identifier, protected with an SHA-256 HMAC truncated to 128 bits. The authorisation details are looked up by a call to the Connect2id token introspection endpoint.
An SPI is provided for plugging alternative identifier generators.
Identifier-based tokens are intended for clients which cannot validate RSA signatures, or for applications which security requires revocation with immediate effect.
19.1 Client X.509 certificate bound access tokens
When mutual TLS is used at the token endpoint, the Connect2id server binds the issued access token to the client’s X.509 certificate. Resource servers can validate the binding by inspecting the x5t#S256 access token claim which represents the SHA-256 thumbprint of the client certificate.
20. Refresh tokens
The Connect2id server issues refresh tokens based on secure 128 bit random identifiers.
Available configurations:
-
Refresh token lifetime (default setting is no expiration).
-
Refresh token update on each use and authorisation update (default setting is no update).
21. 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.
22. Metrics and monitoring
The Connect2id server provides a RESTful endpoint for accessing over 100 useful metrics to monitor usage and performance. The metrics are expored in Dropwizard and Prometheus format.
The collected metrics can also be reported via JMX or Graphite.
23. High-availability and scaling
The Connect2id server can be run in two modes.
-
Standalone – The Connect2id server runs in a single JVM.
-
Cluster – Two or more Connect2id server nodes are clustered for high-availability and load-balancing. Server nodes can be added or removed dynamically. Supported clustering modes:
- Replication – in-memory and cached data, such as sessions, is replicated between the Connect2id server nodes;
- Distribution – in-memory and cached data is distributed across the nodes with some specified redundancy; intended for high loads and large user bases
- Stateless – in-memory and cached data is stored in a external Redis database; for quick, dynamic up / down scaling
24. Runtime
Required runtime:
- Java 8+ JVM
- Servlet 3.0+ compatible container: Apache Tomcat 7+
25. Backend databases
The Connect2id server supports the following backend databases:
For persisting durable data, such as client registrations and long-lived authorisations:
- Relational database:
- MySQL 5.7.8+ (incl. compatible MariaDB editions and AWS AuroraDB DBaaS)
- PostgreSQL 9.5+ (incl. compatible MariaDB editions and AWS AuroraDB DBaaS)
- H2 1.4+ (for testing and development only)
- LDAP v3 directory: OpenLDAP 2.4+, OpenDJ 2.6+
- AWS DynamoDB
For in-memory storage and caching outside Infinispan:
- Redis (including AWS ElastiCache with Redis backend)
26. Hardware Security Module (HSM) support
PKCS#11 compliant Hardware Security Modules are supported:
-
For signing issued ID tokens and self-contained (JWT) access tokens.
-
RSA and EC with P-256, P-384, and P-521 curves.
-
Automatic key roll-over according to the validity window of the key’s X.509 certificate.
Questions or comments?
Get in touch with Connect2id support.