OAuth 2.0 servers
The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application (client) to obtain access on its own behalf without having to expose their credentials.
The OAuth authorization framework includes the following roles:
Resource owner: The resource owner is the person or application that owns the data that is to be shared. For example, a user on Facebook or Google could be a resource owner and the resource they own is their data.
Resource server: The server hosting the protected resources that is capable of accepting and responding to protected resource requests using access tokens. For example, Facebook or Google is a resource server.
Client: An application making protected resource requests on behalf of the resource owner and with its authorization. The term
clienthere does not imply any particular implementation characteristics, such as whether the application executes on a server, a desktop, or other devices. A client application could be TotalAgility requesting access to a user’s Microsoft account.
Authorization server: The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization. The authorization server can be the same server as the resource server or a separate entity.
The following image depicts the typical OAuth authorization grant flow.
TotalAgility, you can define OAuth 2.0 grants and
the mechanisms to get authorizations to interact with various Restful web services. In the
OAuth2 option available for
Web service reference, you can use the configured OAuth 2.0 authorization grants.
TotalAgility supports the following grant types:
Authorization code grant with refresh token grant. TotalAgility automatically refreshes the OAuth 2.0 access token through a system task without user intervention.
Client credentials grant without refresh token grant.
Resource owner password grant with resource owner password credentials.
TotalAgility does not support the following OAuth 2.0 grants and features:
Authorization Code grant without refresh token grant: This grant supports access token generation through manual login or refresh token, but user intervention is not possible during web service execution.
Implicit grant: This grant supports access token generation only through manual login and user intervention is not possible during web service execution.
- Some advanced features of OAuth 2.0 are not supported directly by Kofax TotalAgility due to their uncommon usage, but they can still be used through Custom option in OAuth authentication support. For example, you can authenticate through Assertion-based authentication using JSON Web Token (JWT) with signing algorithm such as RS512 and RS384.