This part of the iSHARE Scheme is considered normative and is therefore compliant with RFC 2119.
iSHARE uses the OAuth 2.0 protocol for authenticating parties and providing access tokens when requesting access to a service within iSHARE.
On this page a brief description of OAuth is provided. For the most recent version of the OAuth 2.0 specification click on this link.
Furthermore this page describes the generic iSHARE Authentication flow.
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 OAuth 2.0 requirements
In addition to the specifications below, for all uses of OAuth 2.0 the following requirements apply:
- Clients MUST NOT be pre registered. A look-up in the iSHARE adherence registry is sufficient. It is up to the server create a new entry for Clients that perform requests for the first time 1
client_idMUST contain the valid iSHARE identifier of the client
- For interoperability reasons clients SHALL only make
HTTP GETcalls to the
- Servers SHALL NOT issue refresh tokens
1 In OAuth 2.0 clients are generally pre-registered. Since in iSHARE servers interact with clients that have been previously unknown this is not a workable requirement. Therefore iSHARE implements a generic client identification and authentication scheme, based on iSHARE whitelisted PKIs.
iSHARE authentication flow
Based on the described standards and specifications in this scheme, the generic iSHARE Authentication flow is described in the following sequence diagram.
Access token specifications in OAuth 2.0
Used to obtain an OAuth access token from a party that exposes an iSHARE API.
Based on the requirements in https://tools.ietf.org/html/rfc6749
OAuth access token API specifications example
Used to obtain an OAuth access token from the Authorisation Registry
OAuth 2.0 grant type. MUST contain “authorization_code”
OAuth 2.0 scope. Defaults to "iSHARE", indicating all rights are requested. Other values MAY be specified by the API owner and allow to get tokens that do not include all rights
OpenID Connect 1.0 client ID. Used in iSHARE for all client identification for OAuth/OpenID Connect. MUST contain a valid iSHARE identifier
OpenID Connect 1.0 client assertion type. Used in iSHARE for all client identification for OAuth/OpenID Connect. MUST contain “urn:ietf:params:oauth:client-assertion-type:jwt-bearer”
OpenID Connect 1.0 client assertion. Used in iSHARE for all client identification for OAuth/OpenID Connect. MUST contain JWT conform iSHARE specifications
Example OAuth token request
OAuth 2.0 general description
OAuth is an open standard for authorisation which is used by i.e. Google, Facebook, Microsoft, Twitter etc. to let their users exchange information about their accounts with other applications or websites. OAuth is designed to work with HTTP.
Through OAuth users can authorise third party applications or websites to access their account information on other "master" systems without the need of exchanging with them their credentials to login onto the platform. OAuth provides a "secure delegated access" to resources (email accounts, pictures accounts, etc.) on behalf of the resource owner.
It specifies a method for resource owners to authorise third parties access to their resources without exchanging their credentials (username, password). Authorisation servers (of the platform) issue access tokens to third party clients (applications or websites) with the approval of the resource owner (= end user). The third party client needs the access token to get access to the resources that are stored on the resource server (of the master system).