The OpenAIRE APIs can be accessed over HTTPS both by authenticated and unauthenticated requests. To achieve better rate limits you need to make authenticated requests. OpenAIRE APIs can be used for both authentication and authorization. This document describes our OAuth 2.0 implementation, which conforms to the OpenID Connect specification, and is OpenID Certified. OpenID Connect is a simple identity layer on top of the OAuth 2.0 protocol. For more information about OAuth2.0 please visit the OAuth2.0 official site. For more information about OpenID Connect please visit the OpenID Connect official site.

We support the creation of personal and service access tokens.

Personal access token

How to create your personal access token

To create your personal access token
  1. Login to OpenAIRE. In case you are not already a member you will need to register first.
  2. Go to your access token page to get your personal access token.

Do not share your personal access token. Send your personal access token only over HTTPS.

How to use your personal access token

To access the OpenAIRE APIs send your personal access token using the Authorization header.

                     
                           GET /api/deposit/depositions
                           Authorization: Bearer ${ACCESS_TOKEN}
                     
                  

The access tokens expire after ???. To get a new access token you can use a refresh token. To get your refresh token

  1. Login to OpenAIRE. In case you are not already a member you will need to register first.
  2. Go to your refresh token page to get your refresh token.

Do not share your refresh token. Send your refresh token only over HTTPS.

Refresh tokens are long-lived. This means that when a client gets a refresh token, this token must be stored securely to keep it from being used by potential attackers. If a refresh token is leaked, it may be used to obtain new access tokens (and access protected resources) until it is either revoked or it expires (which may take a long time). Access tokens must also be kept secret, but security considerations are less strict due to their shorter life.

To get a personal access token using your refresh token you need to make the following request

                     
                        https:beta.services.openaire.eu/uoa-user-management/api/users/getAccessToken?refreshToken=${your_refresh_token}
                     
                  

The response has the following format

                     
                        { "access_token": "...",
                           "token_type":"Bearer",
                           "refresh_token": "...",
                           "expires_in": ...,
                           "scope":"...",
                           "id_token":"..."
                        }
                     
                  

Error Messages

Missing Refresh Token

                     
                        {  "status" : "error", 
                           "code" : "400", 
                           "message" : "Bad Request", 
                           "description" : "Missing refreshToken parameter" 
                        }
                     
                  

Invalid Refresh Token

                     
                        {  "status" : "error", 
                           "code" : "401", 
                           "message" : "Unauthorised", 
                           "description" : "Invalid refreshToken token" 
                        }
                     
                  

Service access tokens

How to create your service access token

To create your service access token you need to register your service.

1. Register your service

To register your service:

  1. Login to OpenAIRE. In case you are not already a member you will need to register first.
  2. Go to your registered services page.
  3. Provide the basic information to register an new service.
2. Create and sign a JWT

Create a client that must create and sign a JWT and include it in the request to token endpoint.

The header should contain the following claims:

  • alg, (required) the “algorithm” that is used to sign the JWT.
  • kid, (required) the “key ID” of the key that was used to sign the JWT.

The payload should contain the following claims:

  • iss, (required) the “issuer” claim identifies the principal that issued the JWT. Value: client_id of the client.
  • sub, (required) the “subject” claim identifies the principal that is the subject of the JWT. Value: client_id of the client.
  • aud, (required) the “audience” claim identifies the recipients that the JWT is intended for. Value: the token endpoint of the issuer.
  • jti, (required) The “JWT ID” claim provides a unique identifier for the JWT. Value: random string.
  • exp, (required) the “expiration time” claim identifies the expiration time on or after which the JWT MUST NOT be accepted for processing. Value: timestamp in epoch format.
  • iat, (optional) the “issued at” claim identifies the time at which the JWT was issued. Value: timestamp in epoch format.

How to use your service tokens

   Unless otherwise indicated, all materials created by OpenAIRE are licenced under CC ATTRIBUTION 4.0 INTERNATIONAL LICENSE.