Last updated
Copyright © 2024 iSHARE Foundation
Last updated
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 .
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.
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
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
Additional rationale
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 .
Based on the described standards and specifications in this scheme, the generic iSHARE Authentication flow is described in the following sequence diagram.
Used to obtain an OAuth access token from a party that exposes an iSHARE API.
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).
Based on the requirements in
Used to obtain an OAuth access token from the Authorisation Registry
Parameter
Contained in
Type
Required
Description
grant_type
query
string
Yes
OAuth 2.0 grant type. MUST contain “authorization_code”
scope
query
string
No
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
client_id
query
string
Yes
OpenID Connect 1.0 client ID. Used in iSHARE for all client identification for OAuth/OpenID Connect. MUST contain a valid iSHARE identifier
client_assertion_type
query
string
Yes
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”
client_assertion
query
string
Yes
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 Bron uitklappen
Responses
Code
Description
200
OK
Example value Bron uitklappen