Roadmap

1. OpenID Connect

1.1 CIBA enhancements

Pending requests queue

Connect2id is working on a plugin that places pre-processed CIBA requests into a queue which native IdP apps or an IdP backend service can poll at a web endpoint. IdP apps that have established a user session access the pending requests for the user by presenting their session ID.

Control the allowed hint types for each client

Identity providers will be given the ability to set the hint types that a client may use in its CIBA requests to the Connect2id server. For example, a client application that deals with transactions may be allowed to use only a login_hint_token in its CIBA requests.

DPoP style binding

Access to the CIBA authorisation endpoint may be configured to require a DPoP proof of the native IdP app private key, in addition to the IdP app session ID.

Ping and push modes

The CIBA ping and push modes can be implemented, subject to customer demand.

The push (callback) mode is the most efficient and responsive of the three, because the client is able to obtain the token(s) as soon as the CIBA authorisation is given (a token request is not required). For extra confidentiality, the callback may be encrypted (JWE) to a public client key registered in the client jwks or jwks_uri metadata.

2. OAuth 2.0

2.1 OAuth 2.0 for first-party applications

In October 2024 the OAuth working group adopted a new draft to develop an alternative to the password grant, with a flexible flow that would enable the Connect2id server to use arbitrary authentication factors when signing users into mobile and desktop apps.

The new OAuth 2.0 grant for first-party apps will complement the available device SSO capability.

2.2 OAuth Incremental Authorisation

OAuth 2.0 authorisation requests from public clients that include every scope the client might ever need can result in over-scoped authorisation and a bad end-user consent experience.
draft-ietf-oauth-incremental-authz adds support for incremental authorisation, the ability to request specific authorization scopes as needed, when they’re needed, removing the requirement to request every possible scope that might be needed upfront.

2.3 OAuth 2.0 Device Authorisation Grant

Commonly known as the device flow, this OAuth grant is for designed for browserless and input constrained devices / contexts, such as smart TVs, consoles and printers. This user authorises the client on secondary device, such their smartphone or personal computer. See RFC 8628.

2.4 Support for Resource Server specific access token profiles

The Connect2id server supports a number of access token profiles, including the definition of custom profiles, there however cannot be bound to specific resources at present.

2.5 Support device session creation in the password grant

This will enable the native applications that use the resource owner password credentials grant to create device sessions for OpenID Connect native SSO.

3. JOSE

3.1 Post-quantum cryptography (PQC) support

Connect2id is working to begin the introduction of PQC signing algorithms in 2026. This will be based on the PQC specifications currently developed at the JOSE working group at the IETF.

4. PKCS#11 / HSM

4.1 HMAC HSM key support

Support for storing the hmac Connect2id server key in a PKCS#11 compliant store.

5. Monitoring

5.1 Tracing support

Tracing with Micrometer.io will be added on paths involving OpenID claims retrieval and the most widely used Connect2id server integration APIs.

Comments, suggestions?

Write to Connect2id support.