Authentication and authorization - 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 organization page of the Safe Share Organization 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 authorized 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 utilizes the OAuth 2.0 Authorization Framework to authenticate and authorize Covata user accounts securely to the Covata Platform. The OAuth 2.0 process (or ‘dance’) to obtain an access token ⁽¹⁾ using the authorization code grant type ⁽²⁾ consists of the following steps:

Your (client) application initiates a request for an authorization code from the Covata Platform.
Note: The authorization 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 authorization code to your application.
Your application makes a subsequent request to the Covata Platform to receive an access token. This 2nd request contains the authorization code and your application’s client credentials.

The authorization 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 Authorization Framework. These additional grant types provide authentication/authorization solutions for a wider range of client application types and are simpler processes than that for the authorization code grant type described above. However, both the implicit and password grant types do not possess all the security features provided by the authorization 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 Safe Share Administrator’s Guide. ⁽²⁾ An OAuth 2.0 grant type is a credential representing a Covata user’s authorization 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	Authorization code
Native desktop/laptop or mobile application	Authorization 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 Authorization 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 authorization 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 organization have in your application.

Registering your application on the Covata Platform

Before developing your application, you should consult your Safe Share 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 Safe Share administrator can proceed with your application’s registration process. Once your application is registered, your Safe Share 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 Safe Share administrator may allow you to generate your own client credentials. See Configuring client applications in the Safe Share 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 authorizing your application to access a Covata user’s resources on the Covata Platform:

Initiating authentication and authorization (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 authorization

The authentication and authorization 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 authorization 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 authorization code grant type

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

<access-service>/api/oauth/authorize

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 authorization 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/authorize?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 authorization code, whose value is the code URL parameter. For example:

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

Step (3) To complete the authentication and authorization 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 authorization_code
code - The value of the authorization 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 authorization 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 'Authorization: Basic ZXhhbXBsZUNsaWVudEFwcGxpY2F0aW9uOmV4YW1wbGVDbGllbnRBcHBsaWNhdGlvblNlY3JldA==' \
    -d 'grant_type=authorization_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 authorization 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/authorize

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/authorize?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 'Authorization: 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 authorization code or password grant type requests

Once the authentication and authorization processes for either the authorization 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 authorization process for the implicit grant type above is successful (via the GET method request to the <access-service>/api/oauth/authorize 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 authorization

​Using the authorization code grant type

​Using the implicit grant type

​Using the password grant type

​Receiving the access token

​From authorization 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 authorization

Using the authorization code grant type

Using the implicit grant type

Using the password grant type

Receiving the access token

From authorization code or password grant type requests

From implicit grant type requests