Can some explain the behavior of OTK Require OAuth2.0 Token?

[Kareem.shaik7]

Can some explain the behavior of OTK Require OAuth2.0 Token?

 

Below is my understanding.

 

- When we see any OTK assertions in Policy Manager it means OTK is installed and configured. (Assumption)

- Configuration includes connectivity from Gateway to OAuth2.0 server (Assumption).

- To authorize the API consumer against OAuth2.0, we need to insert 'OTK Require OAuth2.0 Token' assertion.

- This assertion retrieves AccessToken from header and communicated with OAuth server to get below parameters related to the consumer:

access_token, content-type, error.code, error.msg, session.client_id, session.expires_at, session.scope, 
session.subscriber_id, status.

(AccessToken should have been created from the OAuth API which takes ClientId and SecretKey and Input - Assumption)

- Successful execution of assertion indicated success in OAuth2.0 authentication.

- On success of 'OTK Require OAuth2.0 Token' policy can proceed to execute further assertions. 

 

Can someone validate and correct me if my assumptions and understandings is wrong. 

 

Regards

Kareem

[Simon Crum]

Hi Kareem,

When you see OTK assertions in Policy Manager, it means OTK is installed. However, there are several post-installation configuration tasks required. 

Post-Installation Tasks - CA API Management OAuth Toolkit - 3.5 - CA Technologies Documentation 

The number of these tasks has been reduced in the latest 3.6 version. The UUID is generated for example. 

 

You want to use the OTK Require OAuth2.0 Token assertion as early as possible in the policy. 

Secure an API Endpoint with OAuth - CA API Management OAuth Toolkit - 3.5 - CA Technologies Documentation 

 

The access token is not retreived from the header if you are making an OAuth request using the authorization flow response_type=code. 

Implementation Details - CA API Management OAuth Toolkit - 3.5 - CA Technologies Documentation 

Your other assumptions and your list of parameters looks good to me.  Perhaps saspr02 would have something more to add.

 

Simon

[saspr02]

Hi Kareem!

 

You would use OTK Require OAuth 2.0 Token on any API that requires a valid access_token as input. A client can provide the token in the header "authorization: Bearer <token>" or as Query/ POST body parameter such as "...?access_token=<token>" or "... &access_token=<token>&...".

Passing that assertion means that the given token has been valid.

The variables that you have referenced (...session.client_id, session.expires_at, session.scope...) are all available to the policy for further validations/ processing.

You also asked about retrieving the access_token. A client has to go through any oauth flow first. A client_secret may not be required depending on the type of client (public, confidential) and the used grant_type.