webMethods and Intelligent Business Operations 10.2 | Integration Server Administrator's Guide | Configuring OAuth | Authorization Grant Types Supported by Integration Server | Implicit Grant
 
Implicit Grant
The implicit grant type is used to authenticate browser-based applications and mobile applications. This grant type is less secure than the authorization code grant because it does not require the client to authenticate with the authorization server. In addition, the implicit grant type passes the access token through the resource owner's browser, exposing it to theft by malicious applications on the resource owner's device. The following diagram illustrates how the Integration Server authorization server participates in the implicit grant process.
You use the implicit grant type to authenticate and provide access to public clients. A public client is a client that uses only a client ID for identification, with no other credentials. Public clients are typically implemented in a browser using a scripting language such as JavaScript. Because the authorization server does not require any other credentials, the authorization server grants any client with a valid client ID an access token. To specify a public (implicit) client in Integration Server Administrator, set Type to Public. For more information, see Registering Clients.
Implicit Grant Flow
Stage
Description
1
The client application initiates the process by calling the pub.oauth:authorize service to request access to the resource owner’s data.
2
The pub.oauth:authorize service validates the request. If valid, the service responds with an HTML page that informs the owner that the client application is requesting access within a specified scope. The resource owner uses a form on the HTML page to approve or deny the request.
3
When the resource owner approves the request, the approval page invokes an internal service on Integration Server. If the resource owner denies the request, an error is returned.
4
Integration Server redirects the resource owner's browser to the client application's redirection endpoint, appending the access token as a fragment on the redirection URI.
5
The resource owner’s browser holds the access token in memory until the client application retrieves the access token.
6
The client application uses the access token to execute a service on the resource server.
7
The resource server checks with authorization server to make sure the requested service is within the scope for which the access token was issued and whether the client is authorized to access the folders and services in the scope.

Copyright © 2015- 2018 | 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