Fetching and Using OAuth 2.0 Client Tokens for Consumption
If you are using the OAuth 2.0 protocol and you have successfully registered as a consumer for an API, you should have received your OAuth 2.0 client credentials (a client_id and client_secret).
Now you need to obtain an OAuth 2.0 access token by providing your client credentials to the Mediator-hosted REST service mediator.OAuth 2.0.getOAuth 2.0AccessToken. This service will provide an OAuth 2.0 access token that you can subsequently include in your requests to call the API.
The service's input parameters are:
client_idclient_secret scope (optional). The scope value is the name of the virtual service. If the scope value is valid,
Mediator obtains the access token. If no scope value is provided,
Mediator provides the access token to the scope in which the client is allowed and adds the scope to the response. To provide the scope, include it in the request body.
Ways for Clients to Provide the Inputs
There are three ways in which a client can provide the inputs for this service:
Provide inputs in the Basic authentication header (recommended).
The client can provide the client credentials (client_id and client_secret) in the Authorization header using the following form:
Authorization: Basic <base-64-encoded client_id:password, client_secret>
If you want to provide the scope, include it in the request body.
Provide JSON inputs for the service.
The client can send a JSON request to the service in the following form:
{
"client_id" : "",
"client_secret": "",
"scope" : ""
}
Note:
The client should contain the header Content-type:application/json in the request.
Provide inputs in the request body
The OAuth 2.0 specifications do not support sending the client credentials over the URL as URL-Encoded. However, you can send the client credentials in the request body using the following form:
client_id=<client_id>&client_secret=<client_secret>&scope=<scope>
Note:
The client should contain the header
Content-type:application/x-www-formurlencoded in the request.
If a client provides the client_id and client_secret in both the Authorization header and the request body, the credentials given in the Authorization header are used.
Using HTTPS for Granting Access Tokens
For security reasons Software AG recommends using HTTPS in your production environment. If you are using HTTPS as the transport protocol over which the OAuth 2.0 access tokens are granted authorization, you must set the parameters pg.OAuth 2.0.isHTTPS and pg.OAuth 2.0.ports as described in Administering webMethods Mediator.
Responses Returned to Clients
Following are sample responses that are returned to the client:
Sample XML response:
Sample JSON response:
{
"access_token": "db95b40095f31439a1cd8f411e64abe8",
"token_type": "Bearer",
"expires_in": 3600
}