Skip to content
Connect2id
Connect2id server

First peek at our upcoming OpenID Connect server

Those who have followed our activity in the OpenID Connect work group would know that we’ve been working hard on a server implementation. The OpenID Connect spec suite matured considerably over the past few months and now that the WG has promoted it to 2nd implementers’ draft status we’re preparing to release an alpha to early adopters.

IdP capabilities

The product, which will bear the name Connect2id server, has the following capabilities:

  • Provide Single Sign-On (SSO) and user provisioning to web and native applications.

  • Issue ID tokens, which encapsulate the user identity and its authenticating context in a verifiable manner by means of a JWS signature.

  • Support optional discovery of the OpenID Server as well as dynamic client registration. The client registration can be operated in open or protected mode, depending on the organisation’s requirements.

Organisations that wish to use the OpenID Connect server as a general OAuth 2.0 server can freely do so. The Connect2id server offers a simple web interface to enable binding of additional (custom) scope values and authorisation information to the issued access tokens. These access tokens can then be passed to any third party web API or protected resource.

MS-AD / LDAP support out of the box

The Connect2id server would typically be deployed on the organisation’s premise and linked to an LDAP directory, such as Microsoft’s Active Directory or OpenLDAP, to verify the credentials of the users who sign in with OpenID Connect and then to provision the authorised details at the UserInfo endpoint.

Additional user authentication factors (for 2FA) and risk management controls can be plugged in through a web API exposed by the Connect2id server. We know that customers can have diverse security requirements, so we took extra care to design a configuration API that is flexible enough to cater for any imaginable policy as well as simple to integrate.

Designed for easy scaling and 100% uptime

Login and identity provision is an enterprise service that must be available all the time. To ensure resilience of the server we engineered support for clustered operation, which can span data centres if required. Customers will have peace of mind when hardware and network failures do occur and very large user bases can be effectively handled by spreading the load across the cluster nodes.

Intrigued?

Get in touch with us to find out more about OpenID Connect and how you can utilise it in your business. We at Connect2id have built up considerable expertise on OpenID Connect and the underlying OAuth 2.0 framework, from our participation in the various standard making bodies involved as well as from building concrete software implementations, and we’re ready to answer even the most complicated questions that you may have.

You’re also welcome to sign up to receive a preview version of the Connect2id server.

The specifications

The alpha release of the Connect2id server is based on the OpenID Connect 2nd implementers’ drafts:

  • OpenID Connect Messages 1.0 – draft 20
  • OpenID Connect Standard 1.0 – draft 21
  • OpenID Connect Session Management 1.0 – draft 15
  • OAuth 2.0 Multiple Response Type Encoding Practices – draft 08
  • OpenID Connect Discovery 1.0 – draft 17
  • OpenID Connect Dynamic Client Registration 1.0 – draft 19

The complementary JavaScript Object Signing and Encryption (JOSE) and JSON Web Tokens (JWTs) will be based on the following specs:

  • draft-ietf-jose-json-web-algorithms-11
  • draft-ietf-jose-json-web-signature-11
  • draft-ietf-jose-json-web-encryption-11
  • draft-ietf-jose-json-web-key-11
  • draft-ietf-oauth-json-web-token-08

At its core the Connect2id server will be acting as an OAuth 2.0 authorisation server which is described in:

  • OAuth 2.0 (RFC 6749)
  • OAuth 2.0 Bearer Token (RFC 6750)
  • draft-ietf-oauth-jwt-bearer-05
  • draft-ietf-oauth-dyn-reg-12

The Connect2id server will support two methods for authenticating client applications and securing the ID tokens issued to them:

  • Each client can be provisioned with a client secret. Such clients can then authenticate at the token endpoint with the client_secret_basic, client_secret_post and client_secret_jwt methods. Issued ID tokens will then be secured with a JWS signature based on the HS256, HS384 or HS512 algorithms. Clients that are able to process RSA-based JWS signatures can opt to use the RS256, RS384 or RS512 algorithms instead.

  • Each client can supply a public RSA key to the server when it registers. Such clients can then authenticate at the token endpoint with the private_key_jwt method. Issued ID tokens will then be secured with a JWS signature based on the RS256, RS384 or RS512 algorithms (using the server’s own RSA key).

An OAuth 2.0 / OpenID Connect client registration endpoint will be provided to allow for provisioning, updating and deleting client applications. Customers will have the choice to configure this endpoint for public registration or to restrict registration to trusted parties only. The actual registration can then be done through the endpoint web API or through a manual UI form.

Organisations that want to use access tokens to access other protected resources (not just the UserInfo endpoint) can do so by configuring their own custom scope values and consent policies (implicit / explicit). The issued access tokens can then be verified by a RESTful call to the Connect2id server or by decoding the authorisation information that is contained within the token.