Roadmap
1. OpenID Connect
1.1 CIBA enhancements
Pending requests queue
Connect2id is working on a plugin that puts all successfully pre-processed CIBA requests into a queue, which native IdP apps or an IdP backend service can then 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.
Automatic generation of random, IdP app session-bound user codes
The optional user_code
parameter in CIBA is designed to prevent unsolicited
requests, but it its original definition the onus is on the user to think of a
suitable secret (which must not be their password!) and type it into the client
device. Connect2id suggests a simpler and more secure user_code
facility,
which generates a random, one-time use code, for the IdP app to present to the
client device in a QR code, or pass it via NFC. In call centre scenarios the
code length and character set can be optimised for dictation over the phone.
DPoP style binding
Access to the CIBA authorisation endpoint can be configured to require a DPoP proof of the native IdP app private key, in addition to the IdP app session ID. This ensures the CIBA login and consent in the IdP app is cryptographically bound to the user’s device.
Ping and push modes
The push (callback) mode is the most efficient and responsive of the three
token delivery modes in CIBA, because the client is able to obtain its token(s)
as soon as the user authorises the request (a token request to the Connect2id
server is not required). For extra confidentiality, the callback can 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.