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).
You need to obtain an OAuth 2.0 Access token from one of the REST services hosted by the authorization servers seen below:
REST Services | Hosted by (authorization servers) |
mediator.oauth2:getAccessToken | Mediator |
pub.apigateway.oauth2:getAccessToken | API Gateway |
You can include the obtained OAuth 2.0 access token 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, the authorization server obtains the access token. If no scope value is provided, the authorization server 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.
The following section explains the steps to provide inputs in Mediator. For information on API Gateway, refer to the OAuth Authentication Use case and Workflow section of the API Gateway User Guide.
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 (If Mediator is used as authorization server):
Sample XML response (If API Gateway is used as authorization server):
Sample JSON response:
{
"access_token": "db95b40095f31439a1cd8f411e64abe8",
"token_type": "Bearer",
"expires_in": 3600
}