IT:AD:OpenId Connect (OIDC)

OpenID Connect (OIDC) is an interoperable, simple, secure, flexible, web and mobile friendly authentication protocol extension to the IT:AD:OAuth (an authorisation protocol for authorising the user, and obtaining access tokens to access web APIs and protected resources) to provide to client apps basic user profile info provided in the form oa IT:AD:JWT (a id_token).

OIDC is the 3rd generation of IT:AD:OpenID.

The simplest description I came across on the net is as follows:

penID Connect is a simple identity layer built on top of the OAuth 2.0 protocol. It allows Clients to verify the user's identity based on the authentication performed by the Authorization Server, and to obtain profile information about the user in an inter-operable way.

OpenID Connect introduces a new type of token: the ID Token, that can be requested from the Authorization Server by adding id_token to the response_type parameter in the initial authorization request. In such a situation, after completing the authentication and authorization delegation, the Authorization Server will return an id_token parameter in addition to the code or token parameter (depending on the grant type). The id_token parameter contains a JWT with semi-fixed payload schema. The schema is semi-fixed, because the names of the data fields are fixed: for instance, the user's first name will be always provided in a field called given_name (not first_name or firstName or forename). The standard allows the Client to ask for specific user profile fields, by specifying them as part of the scope: if the scope contains email, two profile fields are included in the JWT payload of the ID Token: email and email_verified. If the scope contains profile, a number of 14 profile fields are going to be provided in the ID Token: given_name, family_name, address, etc. The request for specific user profile fields can be even more granular, by using a new claims parameter. For instance, claims=family_name+email asks for two specific user profile fields to be included in the JWT.

As mentioned above, it is important that the resource server (your server-side application) accept only the access token from a client. This is because access tokens are intended for authorizing access to a resource.

ID Tokens, on the other hand, are intended for authentication. They provide information about the resource owner, to allow you verify that they are who they say they are. Authentication is the concern of the clients. Because of this, when a client makes an authentication request, the ID Token that is returned contains the client_id in the ID Token’s aud claim.¹⁾

An Identity Layer provides:

• Who: is the person that was authenticated
• Where: was he authenticated (IdP)
• When: was he authenticated
• How: was he authenticated
• What: attributes he can give you
• Why: he is providing them
• Interoperable:
  • Standard Scope: openid, profile, email, address, phone
  • Method for asking granular claims: request object and claims
  • ID Token: Info about the authenticated user
  • UserInfo endpoint: Get Attributes about the user, translate the tokens. Simple:
  • Json based
  • Rest friendly
  • Mobile and App ready (relies on tokens, not web only cookies)
• Flexible:
  • Granular requests (JSON + Data Minification)
  • Aggregated claims: does not disclose data recipients to data sources
  • Distributed claims: decentralized data storage of attributes
• Choice of provider:
  • Google, IBM, Microsoft, Ping Identity, ForgeRock, PayPal, etc.