API Management 10.4 | Administering API Portal | Using and Testing APIs | OAuth 2.0 Support
 
OAuth 2.0 Support
 
Testing an OAuth Protected API
The OAuth 2.0 Authorization Framework (OAuth) facilitates the sharing of private resources (data or services) with a third-party client application (client). In an OAuth session, private resources are stored on a resource server and the owner of the resources, or resource owner, grants the client application permission to access them. In this case the resource owner is typically an application. When a resource owner grants permission, the OAuth authorization server issues an access token to the client application. When the client application passes the access token to the resource server, the resource server communicates with the authorization server to validate the token and, if valid, provides access to the resources.
Note: Extensive OAuth2 support is available from API Portal 10.1 and higher versions.
Authorization grant types supported in API Portal
The flow of authorization requests and responses between the resource owner, client application, authorization server, and resource server depends on the authorization grant type defined by the OAuth session. API Portal supports the following authorization grant types:
*Authorization code
*Implicit
*Client credentials
*For an OAuth2 protected API published from CentraSite, only Client credentials grant type is supported.
*All 3 grant types are supported only if the OAuth2 protected API is published from API Gateway 10.1 or higher versions.
Authorization Code Grant
The authorization code grant type is used to authenticate and provide access to clients that have credentials on the authorization server. This grant type requires the client to authenticate to the authorization server before obtaining an access token. The user is prompted to log on to the authorization serve and to authorize or deny the client (application) access to their account. Once authorized, the Authorization provides an authorization code. This authorization code is provided to the Access token URL, which in turn provides the required access token to access the resource.
Implicit Grant
The implicit grant flow is similar to the authorization code grant flow with a distinct difference that the Authorization server provides the access token instead of authorization code. The Client ID and Client secret is passed on to the Authorization URL, for validation. The user is prompted to log on to the authorization server and approve the client. On approval, the required access token is provided to access the resource.
Client Credentials
The simplest of all of the OAuth 2.0 grants, this grant is suitable for machine-to-machine authentication where a specific user's permission to access data is not required. The Client ID and Client secret is passed on to the Access token URL, which in turn provides the required access token to access the resource.

Copyright © 2015- 2019 | Software AG, Darmstadt, Germany and/or Software AG USA, Inc., Reston, VA, USA, and/or its subsidiaries and/or its affiliates and/or their licensors.
Innovation Release