1. OpenID Connect
1.1 OpenID Connect Client Initiated Backchannel Authentication Flow (CIBA)
CIBA is a new flow for decoupled authorisation of transactions, typically taking place on the user's smartphone.
At the 2022 OAuth Security Workshop in Trondheim, Norway, several attacks on CIBA based applications were reported, which prompted the development of a 40+ page Cross Device Flows: Best Current Practices (BCP) document, lead by Pieter Kasselman. At the 2023 OAuth Security Workshop in London further types of attacks were reported and the BCP will likely evolve.
Connect2id is currently revising its implementation strategy for CIBA and arguing for the adoption of an augmented CIBA flow in the BCP where the end-user initiates the flow at the OpenID provider / Authorisation server. In addition to that we are working on providing customers with a special Connect2id server integration API that enable authentication of the channel between the Initiating Device and the Authorisation Device (using BCP terminology) whenever possible.
If you are considering CIBA, please contact our tech support and briefly explain your use case and requirements. This will help us tremendously to design a CIBA integration API that is reasonably secure while supporting a wide range of use cases and applications.
1.2 Native SSO for Android and iOS applications
Based on a specification currently in development in the OpenID Connect working group. It will enable mobile apps to share the OpenID Connect identity and authentication of the end-user where the apps are written by the same vendor.
An extension to enable a mobile app to seamlessly sign-in the end-user into trusted web applications and sites is also being considered. The will improve the overall experience for users when moving between a mobile app and associated web sites.
2. OAuth 2.0
2.1 Rich Authorisation Requests (RAR)
The Rich Authorisation Request (RAR) (RFC 9396) enables authorisation requests to be expressed in a JSON object instead of the simpler "scope" values structure. The JSON object schema enables typing of the requests, to be able to easily differentiate between requests for different purposes, and also defines the common parameters "locations", "actions", "datatypes", "identifier" and "privileges".
One disadvantage of RAR is that they are more complex to use and manage than the simple "scope" parameter.
2.2 OAuth Incremental Authorisation
OAuth 2.0 authorisation requests that include every scope the client might ever need can result in over-scoped authorisation and a bad end-user consent experience. The draft-ietf-oauth-incremental-authz spec enhances the OAuth 2.0 authorisation protocol by adding 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.
The note on CIBA also applies to the device grant.
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.
3. Performance and scaling
3.1 Stateless authorisation sessions
Optional configuration to enable stateless authorisation sessions, to encrypt the session data into the session identifier. Can be used to save database traffic and costs in large deployments.
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.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.
Write to Connect2id support.