Skip to content
Connect2id
Connect2id server

Sneak peek at the upcoming Connect2id server 3.0

In December we started work on a third major release of the Connect2id server for single sign-on and access management based on the emerging OpenID Connect / OAuth 2.0 stack. It captures important feedback that we got from our first server customers and also aims to provide a solid plate for further development in 2015 and beyond.

This is a sneak peek at the new key features that will become part of the 3.0 release.

1. Identity impersonation

The Connect2id server issues signed ID tokens to assert the identity of the user who has been logged in. The new release will also support issue of impersonated ID tokens, to enable privileged users to log in as somebody else. For example, to let administrators log into an app as some regular user.

The Connect2id integration API is flexible and will permit just about any method for controlling access to this privileged feature, e.g. by looking up an attribute in the user’s account (LDAP directory, SQL database, etc.) Care should be taken to always record an audit trail for impersonating logins.

The ID token with have the sub (subject) field set to the ID of the impersonated user, while an additional authz_sub field will contain the ID of the actual authorised subject.

{
  "sub"       : "impersonated_user",
  "authz_sub" : "original_user",
  ...
}

2. Encrypted access tokens

The Connect2id server, as an OAuth 2.0 server, can issue access tokens to grant registered client apps requests to protected resources and web APIs. The access tokens are typically encoded as an RSA-signed JSON Web Token (JWT), which can then be verified by the resource servers with the advertised public RSA key.

To ensure confidentiality of the encoded token parameters, such as the user ID or the authorised scope values, the issued tokens can additionally be encrypted with an AES key. The AES key must be shared between the Connect2id server and all involved resource servers. 128, 192 and 256 AES key lengths are supported, providing various degrees of encryption strength.

3. Expiring refresh tokens

The OAuth 2.0 spec says the lifetime of refresh tokens is indefinite, and the Connect2id server has implemented them initially as permanent (non-expiring).

Non-expiring refresh tokens are good for most situations. However, there might be cases when you may want to limit their lifetime. For instance, with native clients using the password grant, to force end-users to authenticate after a certain time, thus mimicking a behaviour similar to sessions.

The new Connect2id server release will continue issuing permanent refresh tokens by default (these can still be revoked later), but should you wish, you will have the option to set the refresh token for a particular client or end- user to expire after a given amount of time.

If a client tries to refresh an access token and the refresh token has expired, the token endpoint of the Connect2id server will return an invalid_grant error. This can serve as a signal to the client to repeat the authorisation request.

HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
  "error"             : "invalid_grant",
  "error_description" : "Invalid / revoked / expired refresh token"
}

4. Greater control over login and consent

Customers have been able to design just about any login and consent process on top of the Connect2id server, to match specific UX preferences or business criteria. To continue in this spirit we have listened carefully to your suggestions and the next release will include several new features in that area:

  • During the authentication step you will be able to receive the complete client registration details, in order to customise the session parameters or perform some other required operation.

  • The consent step may be automatically skipped if there is existing record for the end-user and client in question.

  • During the consent step you may received a list of all previously consented scope and claim values for the end-user / client combo in question.

5. New metrics and health endpoint

The Connect2id server will provide a protected web endpoint providing over 100 various performance and statistical metrics about the sign-on and authorisation process, the underlying caches and data stores, as well as health checks.

The metrics / health checks can also be exported via JMX.

6. Reduced memory footprint and cluster traffic

The data model has been thoroughly revised, which should result in 20% or more memory saving by the underlying Infinispan caches and maps. Enterprises with very large user bases (1 million plus) should see even greater memory savings.

Serialisation between the Connect2id server cluster nodes was also optimised, to reduce overall network traffic.

All this should allow to handle even larger loads, while reducing your hardware and network bills.

7. Web API security

The web APIs for integrating the login UI, revocation UI, and administrative UIs / clients received a security audit. The session store and authorisation store APIs were modified to prevent leakage of credentials into the logs of web servers.

Most of the above is already in place and we are currently wrapping up a beta release. The official 3.0 release of the Connect2id server is expected later in February.