OpenID Connect 1.0

Owned by Gerard van der Hoeven
Last updated: Oct 31, 2018 by Krijn Reijnders (Unlicensed)
3 min read

This part of the iSHARE Scheme is considered normative and is therefore compliant with RFC 2119.


Besides Machine2Machine interaction, it can occur that it is relevant if a specific person requests data or a service. In order to provide a Service Provider with identity information on a human subject, iSHARE uses the OpenID Connect 1.0 protocol.

The iSHARE use of OpenID Connect 1.0 is based on the requirements from the official standard.

iSHARE facilitates an ecosystem within which parties can interact with previously unknown parties, pre-registration is therefore not a prerequisite and thus requires alterations to the official standard.

Generic OpenID Connect 1.0 requirements

In addition to the endpoint specifications described in the iSHARE Developer Portal, for all uses of OpenID Connect 1.0 the following requirements apply:

  • Clients MUST NOT be pre registered. See Generic/oauth2.0/token for more details.
  • The client_id MUST contain the valid iSHARE identifier of the client
  • For interoperability reasons clients SHALL only make HTTP GET calls to the /oauth2.0/token endpoint. 
  • Servers SHALL NOT issue refresh tokens


Description

OpenID Connect (OIDC) is the authentication layer that is built on top of OAuth 2.0 protocol which is an authorization framework. The OIDC authentication layer allows clients to verify the ID and obtain basic profile information of their end-users

The authentication is performed by the authorization server (managing the access rights and conditions) in an interoperable and REST-like manner.

OpenID Connect's building blocks

OIDC specifies a RESTful HTTP API using JSON as data format.

REST (Representational state transfer) or RESTful web services provide a method to achieve interoperability between computer systems and the internet.

APIs (Application Programming interfaces) enable Machine to Machine (M2M) communication where one machine calls upon the software functionality of another machine. They facilitate connectivity between applications. It is a software architectural approach that revolves around the view on digital interfaces that APIs provide self-service, one-to-many, reusable interfaces.

With OIDC a broad range of clients (web-based, mobile, JavaScript) can request and receive data about authentication sessions end-user profiles.

The specification is extensible (meaning it takes future growth into consideration) and supports optional features for encryption, ID data, discovery of OpenID providers and session management

OpenID Connect 1.0

OpenID Connect 1.0 is an adapted version of OpenID, combined with OAuth 2.0.

OpenID Connect performs many of the same tasks as OpenID 2.0, but in an API-friendly way and usable by native and mobile applications.

OpenID Connect defines optional mechanisms for robust signing and encryption.

Whereas the integration of OAuth 1.0a with OpenID 2.0 required an extension, in OpenID Connect, OAuth 2.0 capabilities are integrated with the protocol itself.


iSHARE H2M authentication flow


Based on the described standards and specifications in this scheme, the generic iSHARE Human2Machine Authentication flow is described in the following sequence diagram.





iSHARE Identity JWTs

The OpenID Connect 1.0 flow contains 2 important iSHARE-specific JWTs, which are described in more detail in this section of the developer portal.

Authorisation in OpenID Connect flow

The generic OpenID Connect 1.0 flow does not take into account Authorisations of a human. However, in iSHARE it is essential that authorisations of a user are combined with their identity details before a service can be offered. This authorisation flow is heavily dependent on the pseudonym used to refer to humans without exposing their identity. This section of the scheme is under construction and parties wishing to implement authorisations of a user are advised to contact support@ishareworks.org.