Authentication and authorisation - Cocoon Data Documentation

All core features of Covata technologies are accessed through a Covata user account, which is registered on the Covata Platform. For more information about Covata users, refer to the Administering users within an organisation page of the SafeShare Organisation Administrator’s Guide. In almost all cases, accessing resources on the Covata Platform through its API requires a Covata user account that has been authenticated and authorised to the Covata Platform. ‘Accessible resources’ on the Covata Platform are resources:

to which a Covata user account is permitted to access, and
is represented by an access token ⁽¹⁾ .

Working with OAuth 2.0 on the Covata Platform

The Covata API utilises the OAuth 2.0 Authorisation Framework to authenticate and authorise Covata user accounts securely to the Covata Platform. The OAuth 2.0 process (or ‘dance’) to obtain an access token ⁽¹⁾ using the authorisation code grant type ⁽²⁾ consists of the following steps:

Your (client) application initiates a request for an authorisation code from the Covata Platform.
Note: The authorisation code is a short string/code, typically alphanumeric, whose purpose is to ensure that this step (and especially the following 2) are connected.
A Covata user authenticates themselves to the Covata Platform (directly) and if this is successful, the Covata Platform sends back an authorisation code to your application.
Your application makes a subsequent request to the Covata Platform to receive an access token. This 2nd request contains the authorisation code and your application’s client credentials.

The authorisation code grant type process for obtaining an access token provides the maximum security features offered by OAuth 2.0, since a Covata user’s credentials are not specified directly through your client application and the client credentials ⁽³⁾ can be kept as secure as possible (on the proviso that your client application is a server-side web application and properly implements TLS). The Covata API also provides support for the implicit and password grant types, which are also part of the OAuth 2.0 Authorisation Framework. These additional grant types provide authentication/authorisation solutions for a wider range of client application types and are simpler processes than that for the authorisation code grant type described above. However, both the implicit and password grant types do not possess all the security features provided by the authorisation code grant type process. ⁽¹⁾ An access token represents a set of accessible resources (available to a Covata user) on the Covata Platform. For more information about Covata Platform access and refresh tokens, refer to the description of the Grant types field on the Configuring client applications page of the SafeShare Administrator’s Guide. ⁽²⁾ An OAuth 2.0 grant type is a credential representing a Covata user’s authorisation to access that user’s protected resources on the Covata Platform. ⁽³⁾ A set of client credentials is an identity for your client application and consists of both a client ID and a client secret. Client credentials are analogous to user credentials, whereby a username/email address and password (for identifying a person) are equivalent to the client ID and client secret, respectively. The following table lists different client application types and the corresponding OAuth grant types best suited for these application types:

Client application type	Recommended OAuth 2.0 grant types
Server-side web application	Authorisation code
Native desktop/laptop or mobile application	Authorisation code ^* or Password ^* (if the client application was developed by Covata)
User agent (e.g. client-side application running in a web browser)	Implicit or Authorisation code (if you would like your application to use refresh tokens to obtain new access tokens)
Administrator/system-run service (e.g. Java scheduled job)	Password

^* When deciding on which of these grant types to implement in your client application, the authorisation code may provide more security or trust than password, in that a Covata user’s credentials are not specified directly through your client application when the user authenticates to the Covata Platform. This grant type decision would most likely amount to the level of trust that parties outside your organisation have in your application.

Registering your application on the Covata Platform

Before developing your application, you should consult your SafeShare administrator to begin the process of registering your application on the Covata Platform. After agreeing on the grant type(s) that your application will implement, your SafeShare administrator can proceed with your application’s registration process. Once your application is registered, your SafeShare administrator should securely issue you with client credentials (a client ID and client secret) to hard code into your application. These credentials are used to ‘authenticate’ your application to the Covata Platform. Be aware, however, that if your application is a native desktop/laptop, a mobile or a user agent-based application, then client credentials are less secure than they would be for a server-side web application (with properly implemented TLS). Therefore in these circumstances, your SafeShare administrator may allow you to generate your own client credentials. See Configuring client applications in the SafeShare Administrator’s Guide for more information.

Overview of the OAuth 2.0 process

The following steps outline the Covata API OAuth 2.0 process for authenticating and authorising your application to access a Covata user’s resources on the Covata Platform:

Initiating authentication and authorisation (initiate the process for obtaining an access token and optional refresh token from the Covata Platform)
Receiving the access token (the Covata Platform responds with the access token)

Initiating authentication and authorisation

The authentication and authorisation process begins by initiating appropriate requests to the Covata Platform to obtain an access token. The nature of these requests differs depending on one of the three supported OAuth 2.0 grant types your application has permission to use:

Once the authentication and authorisation process is successful, an access token is returned to your application. Pass this token in subsequent requests to the Covata Platform to perform other interactions and activities through the Covata API.

Using the authorisation code grant type

Step (1) To obtain an access token from the Covata Platform using the authorisation code grant type, make an initial GET method request to this API endpoint:

<access-service>/api/oauth/authorise

with the following URL parameters:

response_type - Use the value code
client_id - The client ID of your application’s client credentials, which would have been generated when your application was registered on the Covata Platform.
redirect_uri - Your application’s URL/URI, which will handle the initial response from the Covata Platform that contains the actual authorisation code. This initial response is sent after the user has successfully authenticated.

The purpose of this request is to begin the process of authenticating a user to the Covata Platform, by presenting the user with the Covata Sign-in page. Example initial request:

curl https://access-service.xy-company.com/api/oauth/authorise?response_type=code&client_id=exampleClientApplication&redirect_uri=https%3A%2F%2Fmy-application-url%2Fauthcallback \
    -X GET

Step (2) Once the Covata user has successfully authenticated (and if required, has accepted the application approval step), the Covata Platform responds by redirecting to your application’s URL/URI (i.e. the redirect_uri value above) to handle the authorisation code, whose value is the code URL parameter. For example:

https://my-application-url/authcallback?code=lEQmsFkB02NGPaB3YtaDnA

Step (3) To complete the authentication and authorisation process, your application should make a 2nd request to the Covata Platform to this API endpoint (using the POST method):

<access-service>/api/oauth/token

with the following parameters sent as form URL-encoded (i.e. application/x-www-form-urlencoded) data in the request’s body:

grant_type - Use the value authorisation_code
code - The value of the authorisation code returned by the the Covata Platform (and initially handled by your application through the redirect URI).
redirect_uri - Your application’s URL/URI that handled the initial response from the Covata Platform that contained the actual authorisation code.

This 2nd request requires HTTP Basic authentication specified in its header, whose value is the string value of your application’s client ID and client secret (separated by a colon) and encoded with Base64.

The client ID and client secret values constitute your application’s client credentials, which would have been generated when your application was registered on the Covata Platform.

For example, encoding:

exampleClientApplication:exampleClientApplicationSecret
with Base64 results in the value:
ZXhhbXBsZUNsaWVudEFwcGxpY2F0aW9uOmV4YW1wbGVDbGllbnRBcHBsaWNhdGlvblNlY3JldA==

Example 2nd request:

curl https://access-service.xy-company.com/api/oauth/token \
    -H 'Authorisation: Basic ZXhhbXBsZUNsaWVudEFwcGxpY2F0aW9uOmV4YW1wbGVDbGllbnRBcHBsaWNhdGlvblNlY3JldA==' \
    -d 'grant_type=authorisation_code' \
    -d 'code=lEQmsFkB02NGPaB3YtaDnA' \
    -d 'redirect_uri=https://my-application-url/authcallback' \
    -X POST

Submitting a cURL command like the one above with at least one -d option results in the following header:
Content-Type: application/x-www-form-urlencoded
being automatically included in the request. Be aware that this header is required for the request to succeed.

The Covata Platform responds with an access token. Continue on to Receiving the access token from authorisation code grant type requests for details.

Using the implicit grant type

To obtain an access token from the Covata Platform using the implicit grant type, make a single GET method request to this API endpoint:

<access-service>/api/oauth/authorise

with the following URL parameters:

response_type - Use the value token
client_id - The client ID of your application’s client credentials, which would have been generated when your application was registered on the Covata Platform.
redirect_uri - Your application’s URL/URI, which will handle the response from the Covata Platform that contains the access token itself. This response is sent after the user has successfully authenticated.

The purpose of this request is to begin the process of authenticating a user to the Covata Platform, by presenting the user with the Covata Sign-in page, which if successful, results in the direct retrieval of the access token. Example request:

curl https://access-service.xy-company.com/api/oauth/authorise?response_type=token&client_id=exampleClientApplication&redirect_uri=https%3A%2F%2Fmy-application-url%2Fauthcallback \
    -X GET

Once the Covata user has successfully authenticated, the Covata Platform responds with an access token. Continue on to Receiving the access token from implicit grant type requests for details.

Using the password grant type

To obtain an access token from the Covata Platform using the password grant type, simply make a single POST method request to this API endpoint:

<access-service>/api/oauth/token

with the following parameters sent as form URL-encoded (i.e. application/x-www-form-urlencoded) data in the request’s body:

grant_type - Use the value password
username - The email address of a Covata user’s credentials (acquired through your application).
password - The password of a Covata user’s credentials (acquired through your application).

Like above, this request requires HTTP Basic authentication specified in its header, whose value is the string value of your application’s client ID and client secret (separated by a colon) and encoded with Base64.

The client ID and client secret values constitute your application’s client credentials, which would have been generated when your application was registered on the Covata Platform.

For example, encoding:

exampleClientApplication:exampleClientApplicationSecret
with Base64 results in the value:
ZXhhbXBsZUNsaWVudEFwcGxpY2F0aW9uOmV4YW1wbGVDbGllbnRBcHBsaWNhdGlvblNlY3JldA==

Example request:

curl https://access-service.xy-company.com/api/oauth/token \
    -H 'Authorisation: Basic ZXhhbXBsZUNsaWVudEFwcGxpY2F0aW9uOmV4YW1wbGVDbGllbnRBcHBsaWNhdGlvblNlY3JldA==' \
    -d 'grant_type=password' \
    --data-urlencode 'username=alex.originator@xy-company.com' \
    --data-urlencode 'password=password1' \
    -X POST

The Covata Platform responds with an access token. Continue on to Receiving the access token from password grant type requests for details.

Receiving the access token

From authorisation code or password grant type requests

Once the authentication and authorisation processes for either the authorisation code or password grant type above is successful (via the final POST method request to the <access-service>/api/oauth/token API endpoint), the Covata Platform responds with an access token in the body of the response (as a JSON object) as well as a refresh token (if your registered client application on the Covata Platform has been configured to issue one). Example response:

{
    "access_token": "eyJhbGciOiJSUzI1NiJ9.eyJleHAiOjE0NjcwMTY2NjYsInVzZXJfbmFtZSI6ImFsZXgub3JpZ2luYXRvckB4eS1jb21wYW55LmNvbSIsImF1dGhvcml0aWVzIjpbIlBFUk1fRklMRV9ERUxFVEUiLCJQRVJNX0FQUF9BUFBST1ZBTF9SRVZPS0UiLCJQRVJNX1ZJRVciLCJQRVJNX1VTRVJJTkZPX0dFVF9OT1RJRllfUFJFRiIsIlBFUk1fUFJJTlQiLCJQRVJNX0FQSV9WMV9BQ0NFU1MiLCJQRVJNX1NFTEZfUkVWT0tFX1RPS0VOUyIsIlBFUk1fTU9WRSIsIlBFUk1fVVNFUklORk9fR0VUU0VMRiIsIlBFUk1fUkVOQU1FIiwiUEVSTV9BUElfT0FVVEhfQUNDRVNTIiwiUEVSTV9WSUVXX09USEVSIiwiUEVSTV9ERVZJQ0VfQVVUSEVOVElDQVRJT04iLCJQRVJNX0ZJTEVfQUREIiwiUEVSTV9DT05UQUNUU19MSVNUIiwiUEVSTV9GT0xERVJfQUREIiwiUEVSTV9VU0VSSU5GT19FRElUX05PVElGWV9QUkVGIiwiUEVSTV9GT0xERVJfREVMRVRFIiwiUk9MRV9PUklHSU5BVE9SIiwiUEVSTV9PQVVUSF9UT0tFTl9SRVZPS0UiLCJQRVJNX1NFTkRfSVRFTV9OT1RJRklDQVRJT04iLCJQRVJNX1NIQVJFIiwiUEVSTV9BUElfQUNDT1VOVF9BQ0NFU1MiLCJQRVJNX0RPV05MT0FEIiwiUEVSTV9DT05UQUNUU19VUERBVEUiLCJQRVJNX0xBQkVMX0xJU1QiLCJQRVJNX0FQUF9BUFBST1ZBTF9MSVNUIiwiUEVSTV9PUkdBTklTQVRJT05fR0VUU0VMRiIsIlBFUk1fT0FVVEhfVE9LRU5fTElTVF9CWV9DTElFTlQiLCJQRVJNX0FQSUNMSUVOVF9BREQiLCJQRVJNX0FQSUNMSUVOVF9MSVNUIiwiUEVSTV9ERUxFVEVfT1RIRVIiLCJQRVJNX09BVVRIX1RPS0VOX0xJU1QiLCJQRVJNX0FERFJFU1NCT09LX0xJU1QiLCJQRVJNX0NPUFkiLCJQRVJNX0NPTlRBQ1RTX0NSRUFURSIsIlBFUk1fUkVNT1ZFX1NFTEYiLCJQRVJNX0NPTlRBQ1RTX0RFTEVURSIsIlBFUk1fVVNFUklORk9fVVBEQVRFIl0sImp0aSI6ImYxY2Q4NGVhLWM2ZTgtNDc4OC04NzliLTEzZDM0ZDQ0ZDUyNiIsImNsaWVudF9pZCI6ImV4YW1wbGVDbGllbnRBcHBsaWNhdGlvbiIsInNjb3BlIjpbIlNDT1BFX09BVVRIX1RPS0VOX0xJU1QiLCJTQ09QRV9DT05UQUNUU19MSVNUIiwiU0NPUEVfT0FVVEhfVE9LRU5fUkVWT0tFIiwiU0NPUEVfRklMRV9ERUxFVEUiLCJTQ09QRV9GSUxFX0FERCIsIlNDT1BFX0ZPTERFUl9BREQiLCJTQ09QRV9BUElfVjFfQUNDRVNTIiwiU0NPUEVfQVBJQ0xJRU5UX0FERCIsIlNDT1BFX1NFTkRfSVRFTV9OT1RJRklDQVRJT04iLCJTQ09QRV9VU0VSSU5GT19FRElUX05PVElGWV9QUkVGIiwiU0NPUEVfREVWSUNFX0FVVEhFTlRJQ0FUSU9OIiwiU0NPUEVfQ09OVEFDVFNfVVBEQVRFIiwiU0NPUEVfRk9MREVSX0RFTEVURSIsIlNDT1BFX01PVkUiLCJTQ09QRV9PQVVUSF9UT0tFTl9MSVNUX0JZX0NMSUVOVCIsIlNDT1BFX1JFTU9WRV9TRUxGIiwiU0NPUEVfU0VMRl9SRVZPS0VfVE9LRU5TIiwiU0NPUEVfVklFVyIsIlNDT1BFX0NPTlNPTEVfQURNSU5fQUNDRVNTIiwiU0NPUEVfQVBJQ0xJRU5UX0xJU1QiLCJTQ09QRV9BRERSRVNTQk9PS19MSVNUIiwiU0NPUEVfU0hBUkUiLCJTQ09QRV9VU0VSSU5GT19VUERBVEUiLCJTQ09QRV9BQ0xfQURNSU4iLCJTQ09QRV9DT05UQUNUU19ERUxFVEUiLCJTQ09QRV9BUFBfQVBQUk9WQUxfUkVWT0tFIiwiU0NPUEVfUFJJTlQiLCJTQ09QRV9VU0VSSU5GT19HRVRfTk9USUZZX1BSRUYiLCJTQ09QRV9WSUVXX09USEVSIiwiU0NPUEVfUkVOQU1FIiwiU0NPUEVfQ09OVEFDVFNfQ1JFQVRFIiwiU0NPUEVfREVMRVRFX09USEVSIiwiU0NPUEVfQVBJX09BVVRIX0FDQ0VTUyIsIlNDT1BFX0RPV05MT0FEIiwiU0NPUEVfQVBQX0FQUFJPVkFMX0xJU1QiLCJTQ09QRV9VU0VSSU5GT19HRVRTRUxGIiwiU0NPUEVfQ09QWSJdfQ.XMEGyBnYEfy8dAPnJhchYlSJGreBRYGN1KbSF4DZoM6aegIPuSd-hES-nDH56ErrY-xLoMnrWYNeBKEE-Z1eJ6Y2qTnUexebWe7FMcqlVDRSKKQHw2pvcchRMuET3DibxwMZv-JwYcgb1npOWQL5ESRD38k-4kKoVfLfmStkm3kGuPsOr7db2kj6mQF8eMuvXjplzUMU2o42YdgBxLQ0jPcN-FM9yGxFJhWqZ_u6J45Fjlcc1SNYtgQZbwdd4IhfuBtLXqfeEVnNA7gRuNBwsEgBqx3G-i1xtu7ibt8i382JBO0gNmkxxPEK-E5tys-0EwOEv1i42_EYX7nBKd5i5A",
    "token_type": "bearer",
    "refresh_token": "75605643-a194-4bfc-a379-0d0154ab9783",
    "jti": "f1cd84ea-c6e8-4788-879b-13d34d44d526"
}

From implicit grant type requests

Once the authentication and authorisation process for the implicit grant type above is successful (via the GET method request to the <access-service>/api/oauth/authorise API endpoint), the Covata Platform responds by redirecting to your application’s URL/URI (i.e. the redirect_uri value above) with an access token as a URL parameter (amongst other parameters). Example response:

https://my-application-url/authcallback&access_token=eyJhbGciOiJSUzI1NiJ9.eyJleHAiOjE0NjcwMTY2NjYsInVzZXJfbmFtZSI6ImFsZXgub3JpZ2luYXRvckB4eS1jb21wYW55LmNvbSIsImF1dGhvcml0aWVzIjpbIlBFUk1fRklMRV9ERUxFVEUiLCJQRVJNX0FQUF9BUFBST1ZBTF9SRVZPS0UiLCJQRVJNX1ZJRVciLCJQRVJNX1VTRVJJTkZPX0dFVF9OT1RJRllfUFJFRiIsIlBFUk1fUFJJTlQiLCJQRVJNX0FQSV9WMV9BQ0NFU1MiLCJQRVJNX1NFTEZfUkVWT0tFX1RPS0VOUyIsIlBFUk1fTU9WRSIsIlBFUk1fVVNFUklORk9fR0VUU0VMRiIsIlBFUk1fUkVOQU1FIiwiUEVSTV9BUElfT0FVVEhfQUNDRVNTIiwiUEVSTV9WSUVXX09USEVSIiwiUEVSTV9ERVZJQ0VfQVVUSEVOVElDQVRJT04iLCJQRVJNX0ZJTEVfQUREIiwiUEVSTV9DT05UQUNUU19MSVNUIiwiUEVSTV9GT0xERVJfQUREIiwiUEVSTV9VU0VSSU5GT19FRElUX05PVElGWV9QUkVGIiwiUEVSTV9GT0xERVJfREVMRVRFIiwiUk9MRV9PUklHSU5BVE9SIiwiUEVSTV9PQVVUSF9UT0tFTl9SRVZPS0UiLCJQRVJNX1NFTkRfSVRFTV9OT1RJRklDQVRJT04iLCJQRVJNX1NIQVJFIiwiUEVSTV9BUElfQUNDT1VOVF9BQ0NFU1MiLCJQRVJNX0RPV05MT0FEIiwiUEVSTV9DT05UQUNUU19VUERBVEUiLCJQRVJNX0xBQkVMX0xJU1QiLCJQRVJNX0FQUF9BUFBST1ZBTF9MSVNUIiwiUEVSTV9PUkdBTklTQVRJT05fR0VUU0VMRiIsIlBFUk1fT0FVVEhfVE9LRU5fTElTVF9CWV9DTElFTlQiLCJQRVJNX0FQSUNMSUVOVF9BREQiLCJQRVJNX0FQSUNMSUVOVF9MSVNUIiwiUEVSTV9ERUxFVEVfT1RIRVIiLCJQRVJNX09BVVRIX1RPS0VOX0xJU1QiLCJQRVJNX0FERFJFU1NCT09LX0xJU1QiLCJQRVJNX0NPUFkiLCJQRVJNX0NPTlRBQ1RTX0NSRUFURSIsIlBFUk1fUkVNT1ZFX1NFTEYiLCJQRVJNX0NPTlRBQ1RTX0RFTEVURSIsIlBFUk1fVVNFUklORk9fVVBEQVRFIl0sImp0aSI6ImYxY2Q4NGVhLWM2ZTgtNDc4OC04NzliLTEzZDM0ZDQ0ZDUyNiIsImNsaWVudF9pZCI6ImV4YW1wbGVDbGllbnRBcHBsaWNhdGlvbiIsInNjb3BlIjpbIlNDT1BFX09BVVRIX1RPS0VOX0xJU1QiLCJTQ09QRV9DT05UQUNUU19MSVNUIiwiU0NPUEVfT0FVVEhfVE9LRU5fUkVWT0tFIiwiU0NPUEVfRklMRV9ERUxFVEUiLCJTQ09QRV9GSUxFX0FERCIsIlNDT1BFX0ZPTERFUl9BREQiLCJTQ09QRV9BUElfVjFfQUNDRVNTIiwiU0NPUEVfQVBJQ0xJRU5UX0FERCIsIlNDT1BFX1NFTkRfSVRFTV9OT1RJRklDQVRJT04iLCJTQ09QRV9VU0VSSU5GT19FRElUX05PVElGWV9QUkVGIiwiU0NPUEVfREVWSUNFX0FVVEhFTlRJQ0FUSU9OIiwiU0NPUEVfQ09OVEFDVFNfVVBEQVRFIiwiU0NPUEVfRk9MREVSX0RFTEVURSIsIlNDT1BFX01PVkUiLCJTQ09QRV9PQVVUSF9UT0tFTl9MSVNUX0JZX0NMSUVOVCIsIlNDT1BFX1JFTU9WRV9TRUxGIiwiU0NPUEVfU0VMRl9SRVZPS0VfVE9LRU5TIiwiU0NPUEVfVklFVyIsIlNDT1BFX0NPTlNPTEVfQURNSU5fQUNDRVNTIiwiU0NPUEVfQVBJQ0xJRU5UX0xJU1QiLCJTQ09QRV9BRERSRVNTQk9PS19MSVNUIiwiU0NPUEVfU0hBUkUiLCJTQ09QRV9VU0VSSU5GT19VUERBVEUiLCJTQ09QRV9BQ0xfQURNSU4iLCJTQ09QRV9DT05UQUNUU19ERUxFVEUiLCJTQ09QRV9BUFBfQVBQUk9WQUxfUkVWT0tFIiwiU0NPUEVfUFJJTlQiLCJTQ09QRV9VU0VSSU5GT19HRVRfTk9USUZZX1BSRUYiLCJTQ09QRV9WSUVXX09USEVSIiwiU0NPUEVfUkVOQU1FIiwiU0NPUEVfQ09OVEFDVFNfQ1JFQVRFIiwiU0NPUEVfREVMRVRFX09USEVSIiwiU0NPUEVfQVBJX09BVVRIX0FDQ0VTUyIsIlNDT1BFX0RPV05MT0FEIiwiU0NPUEVfQVBQX0FQUFJPVkFMX0xJU1QiLCJTQ09QRV9VU0VSSU5GT19HRVRTRUxGIiwiU0NPUEVfQ09QWSJdfQ.XMEGyBnYEfy8dAPnJhchYlSJGreBRYGN1KbSF4DZoM6aegIPuSd-hES-nDH56ErrY-xLoMnrWYNeBKEE-Z1eJ6Y2qTnUexebWe7FMcqlVDRSKKQHw2pvcchRMuET3DibxwMZv-JwYcgb1npOWQL5ESRD38k-4kKoVfLfmStkm3kGuPsOr7db2kj6mQF8eMuvXjplzUMU2o42YdgBxLQ0jPcN-FM9yGxFJhWqZ_u6J45Fjlcc1SNYtgQZbwdd4IhfuBtLXqfeEVnNA7gRuNBwsEgBqx3G-i1xtu7ibt8i382JBO0gNmkxxPEK-E5tys-0EwOEv1i42_EYX7nBKd5i5A&token_type=bearer&scope=&jti=f1cd84ea-c6e8-4788-879b-13d34d44d526

​Working with OAuth 2.0 on the Covata Platform

​Registering your application on the Covata Platform

​Overview of the OAuth 2.0 process

​Initiating authentication and authorisation

​Using the authorisation code grant type

​Using the implicit grant type

​Using the password grant type

​Receiving the access token

​From authorisation code or password grant type requests

​From implicit grant type requests

Working with OAuth 2.0 on the Covata Platform

Registering your application on the Covata Platform

Overview of the OAuth 2.0 process

Initiating authentication and authorisation

Using the authorisation code grant type

Using the implicit grant type

Using the password grant type

Receiving the access token

From authorisation code or password grant type requests

From implicit grant type requests