Application Integration (On-Premises) : Integration Server Built-In Services : OAuth Folder : pub.oauth:getAccessToken
pub.oauth:getAccessToken
Requests an access token from the authorization server.
The authorization server validates the request and generates an access token and a refresh token (if one is requested). The tokens, along with the client identifier, token expiration interval, and scope are stored in the authorization server's cache.
Input Parameters
grant_type
String Specifies the type of grant flow required by the client.
Since this service is for authorization code grant flows, you must specify authorization_code.
client_id
String The client identifier generated by the authorization server when the client application is registered. The client_id is used to authenticate the client to the authorization server.
Public clients must provide a value for client_id. Confidential clients do not need to provide a value for this parameter because they are required to use HTTP authentication to identify themselves.
code
String The OAuth authorization code received from the authorization server.
redirect_uri
String The URI the authorization server will use to redirect the client when the client is authorized.
Output Parameters
access_token
String The access token issued by the authorization server.
token_type
String The type of access token issued by the authorization server. The value is Bearer.
expires_in
String The number of seconds for which the access token is valid.
refresh_token
String Optional. The refresh token issued by the authorization server. You can use this token to obtain new access tokens using the same authorization grant.
If the client is registered with a refresh limit of 0, no refresh token is issued.
Usage Notes
This service is used with authentication code grant flows only.
This service must be invoked using HTTPS unless the Require HTTPS setting on the Security > OAuth > Edit OAuth Global Settings page is disabled.
Clients must invoke this service via an HTTP POST request.
Confidential clients must authenticate requests by supplying their credentials in the HTTP Authorization header.
Authentication code is not persisted in the cache. If Integration Server is restarted after the authorization code is issued but before the access token is requested, Integration Server will reject the request for the access token.
When Integration Server acts as the authorization server, the token_type output parameter is always Bearer. The authorization server retains the information about the bearer tokens it issues, including the user information. When the client presents a bearer token to the resource server, the resource server checks with the authorization server to see whether the user is allowed to access the requested folders and services.
The tokens, authorization codes, and client information are stored in the authorization server's caches. By default, these caches maintain up to 1000 elements in memory and 10000 elements on disk. If the cache size is exceeded, OAuth performance can be affected on Integration Server and can lead to errors if the disk runs out of space. If you anticipate that your authorization server's cache will exceed the default size, you should increase the Maximum Elements In Memory, Maximum Elements On Disk, or Maximum Off-Heap settings for Integration Server. For information about changing these settings, see webMethods Integration Server Administrator’s Guide. If the cache is distributed, see the BigMemory Max product documentation for 4.1 at www.terracotta.org/documentation for additional considerations when sizing distributed caches.
Copyright © 2015- 2017 Software AG, Darmstadt, Germany. (Innovation Release)

Product LogoContact Support   |   Community   |   Feedback