Client OAuth security
Client OAuth security is configured when Sentinet virtual service's outbound side must send an OAuth token to a business service/API. Effectively, the virtual service in this case must execute as an OAuth user application that is responsible for acquiring OAuth tokens from an OAuth server and sending them to the business service configured with OAuth security. How the actual user application communicates with the virtual service is irrelevant to the OAuth protocol, and considered to be internal security between user application and Sentinet virtual service (for example it can be Basic Authentication, Windows Integrated, mutual X.509 SSL or some other non-OAuth security model). Figure below shows messages exchange flow for the Client OAuth security.
Sentinet virtual service uses security credentials to make a call to
OAuth server (step 1).
It receives an OAuth (JWT) token from the OAuth server and sends it in
its request message to a business service/API (step 2).
Business service is responsible for the validation of the OAuth token
issued by trusted OAuth server.
Note
Sentinet virtual service does not have to contact OAuth server for each request message that comes from the User application (step 1 on the diagram above). Virtual service can cache locally OAuth tokens to avoid repeated calls to OAuth server. Sentinet caching is driven by the combination of the OAuth server token expiration policy and Sentinet internal caching configuration.
Note
In some configuration cases (described later in the Policy Configurations for OAuth security) virtual service may issue an “initiation” call to the OAuth server before exchanging security credentials for OAuth tokens. This call allows Sentinet to learn about (or refresh existing knowledge of) OAuth server’s metadata before the virtual service exchanges its client credentials for OAuth tokens.
As an API Management infrastructure, Sentinet supports the non-interactive OAuth authentication flows: Client Credentials Grant, Resource Owner Grant and Token Exchange.
Client Credentials Grant
Client Credentials Grant authentication flow requires the OAuth client application (virtual service in this case) to submit at minimum its application Client Id and Client Secret to the OAuth server. In some cases, the OAuth server may require additional information to be sent (for example: scope or audience).
Resource Owner Grant
Resource Owner Grant authentication flow requires the OAuth client application (virtual service in this case) to submit at minimum its application Client Id, Client Secret and the resource owner's Username, Password credentials to the OAuth server. In some cases, OAuth server may require additional information to be sent (for example: scope or audience).
Token Exchange Flow
Token Exchange flow is an extension to OAuth 2.0 for implementing scenarios where one token needs to be swapped for another (RFC8693).