As APIM provides an extra layer wrapping up various APIs from your internal applications, it only makes sense to make those API Products secure.

In my blog series SAP API Management | Part 4 | Managing APIs, I demonstrated one such method, i.e. Verify API Key, in which the application presents its API key in the header and APIM validates it against issued app keys from Business Hub.

In this blog, I will cover “how to use APIMs own Auth server to generate and validate OAuth Access token” to secure your exposed APIs.

Table of Contents

  1. Table of Contents
  2. Explaning OAuth 2.0
  3. General Components of Authentication Flow
    1. Components of Auth Flow
    2. Steps involved in Authentication Flow
  4. Excercise: Configuring OAuth2.0 on API Proxy/Products
    1. Prerequisites
    2. Objective
    3. Configuration Hands-On
      1. Objective 1
      2. Objective 2
      3. Objective 3
    4. Testing
      1. Testing Individual OAuth Flow
      2. Using OAuth for Complete API Product
  5. A few notes
  6. Conclusion

Explaning OAuth 2.0

OAuth 2.0 is a protocol that allows applications to securely access resources on behalf of users without sharing their credentials. It enables delegated access, where an application can obtain limited access to a user’s resources hosted by another service, such as social media accounts or cloud storage, without exposing the user’s password. This is achieved through the exchange of tokens, typically bearer tokens, which grant access for a specific scope and duration.

General Components of Authentication Flow

Components of Auth Flow

An API authentication architecture typically consists of multiple components working together to ensure secure access to the API. Here are the key components:

  1. Authentication Server: This component is responsible for authenticating users and issuing access tokens. It verifies the identity of clients (applications or users) based on credentials provided and generates tokens that can be used to access protected resources.
  2. User Database: This is where user credentials are stored securely. It can be a database, directory service (such as LDAP), or an identity provider (IdP) like Active Directory or OAuth providers such as Google or Facebook.
  3. Authorization Server: In architectures like OAuth 2.0, the authorization server is responsible for granting access tokens to clients after successfully authenticating users and obtaining their consent. It also enforces access policies based on scopes and permissions associated with the tokens.
  4. API Gateway: The API gateway acts as an intermediary between clients and backend services. It is responsible for routing requests, enforcing security policies, and handling authentication and authorization. The gateway can perform tasks such as rate limiting, caching, and logging as well.
  5. Access Tokens: Access tokens are credentials that allow clients to access protected resources on behalf of a user. These tokens are typically short-lived and can be scoped to limit the actions a client can perform. They are obtained from the authentication or authorization server after successful authentication and authorization.
  6. Refresh Tokens: Refresh tokens are long-lived credentials used to obtain new access tokens without requiring the user to re-authenticate. They are typically used in conjunction with short-lived access tokens to provide a better balance between security and usability.
  7. Client Application: This is the application or service that interacts with the API on behalf of the user. It must authenticate with the authentication server and obtain access tokens to access protected resources.
  8. Resource Server: The resource server hosts the protected resources that the client wants to access. It is responsible for validating access tokens and granting access to authorized clients.
  9. API Endpoints: These are the endpoints exposed by the API that clients can interact with to perform various operations. Each endpoint may have different authentication and authorization requirements based on the sensitivity of the data being accessed.
  10. Security Protocols and Standards: These include protocols like OAuth 2.0, OpenID Connect, and standards like JSON Web Tokens (JWT) for token-based authentication and authorization. They provide a framework for implementing secure authentication and access control mechanisms in API architectures.

These components work together to establish a secure and reliable authentication architecture for APIs, ensuring that only authorized clients can access protected resources while maintaining the confidentiality and integrity of sensitive data.

Steps involved in Authentication Flow

Below is general flow of actions and operation performed by various components to authenticate an API Call.

  1. Client Authentication:
    • The client application initiates the authentication process by sending a request to the authentication server.
    • The authentication server verifies the client’s identity and authorization to access authentication services.
  2. User Authentication:
    • Simultaneously, the authentication server authenticates the user’s identity against the user database or identity provider.
    • Upon successful authentication, the authentication server issues an authentication token or establishes a session for the user.
  3. Access Token Retrieval:
    • The authentication server sends the authentication token (such as a session cookie or JWT) back to the client application in the response to the authentication request.
  4. Authorization Request:
    • The client application includes the authentication token in subsequent requests to the authorization server to request access to specific resources.
  5. Authorization Grant:
    • The authorization server receives the authorization request along with the authentication token and evaluates the user’s permissions and scopes.
    • Based on the user’s identity and requested actions, the authorization server issues an access token representing the user’s authorization to access specific resources.
  6. API Request with Access Token:
    • The client application includes the access token in subsequent API requests to the resource server. This token serves as proof of the user’s authorization to access the requested resources.
  7. Resource Server Authorization:
    • The resource server receives the API request along with the access token and validates the token’s authenticity and scope.
    • If the access token is valid and grants sufficient permissions for the requested resource, the resource server proceeds with processing the request and provides the requested data or performs the requested action.
  8. Token Refreshing (Optional):
    • If the access token expires or requires refreshing, the client application can use a refresh token to obtain a new access token without requiring the user to re-authenticate.
    • The client application sends a token refresh request to the authentication server, which validates the refresh token and issues a new access token if successful.
  9. Access Revocation (Optional):
    • At any point, if there are concerns about the security of the access token (e.g., if it’s compromised), the authentication server can revoke the token, rendering it invalid for further use.

So, putting all the information together, below is a visual representation of a complete API call, highlighting the roles of the various components of call authorization.

Now that we have basic theory of Authentication sorted. Lets move on hands on excercise:

Excercise: Configuring OAuth2.0 on API Proxy/Products

We have an API which calls the catalog service of the NorthWind OData service. As this service is openly available on the internet without authentication, it is an ideal choice to demo our OAuth configuration to protect it or similar APIs, which may not have great authentication mechanisms in place, i.e. basic auth.

Prerequisites

  1. You must have fair understanding of API lifecycle and steps involved. You can go through my Blog series from Part 1 to Part 6 about SAP APIM, to complete this pre-requisite.
  2. You should have a basic API proxy already created. You can use NorthWind OData service as seen in my blog series. I will use same for demonstration here.
  3. You should have postman client installed to test APIs. SAPs Integration Suite’s Test API features is very buggy, we will not use it here.

Objective

  1. First we will show that the NorthWind API wrapped in API proxy can be accessed w/o any Authentication.
  2. Then, we will set up OAuth flow to generate token. We will show the token in response.
  3. Then, we will use values and configurations from objective 2, to secure our all APIs of an API product using OAuth mechanism.

Configuration Hands-On

Objective 1

So, based on the exercise from my blog series, you should have a Product with a catalog API, which can be accessed without Authentication.

So, we see our API Proxy is exposed as doesnt require any authentication to be protected. We want to enforce the client application to provide access token to be able to access these resources/APIs.

Objective 2

Lets create OAuth flow i.e. one additional API proxy to fetch the token.

Fill in the details as shown:

Hit “Create” and Navigate to “proxy endpoint”. Change “Target Endpoint” from ‘default’ to ‘None’.

The default target endpoint takes you to the one configured during creation of proxy. When you select None, it takes the default APIM endpoint (bypassing any target endpoints configured) which returns the original message body back to the client.

But our client wants OAuth token to be returned instead of the request message body, so we need to enforce a policy called OAuth 2.0 to the Proxy Endpoint PreFlow. Go to Policies->Edit of the API proxy we just created.

Hit “Add”. Update the policy template with this:

false GenerateAccessToken client\_credentials

Hit “Update” and then “Deploy” the proxy:

Now, let’s add this proxy to our API Product. If you haven’t created a product yet, you can create one and add both the proxies to it, i.e. NorthWind Catalog service and Fetch Token service. This exercise is covered in my blog “Publish your APIs”

Objective 3

Now that we have an API Proxy which can generate the token, we will use the configuration of this proxy to generate a token for complete API Product.

However, when we pass the token in our API Call, we need to validate it against the API Auth server to make sure it is a valid token. For that, we will again use OAuth2.0 policy as shown below.

Open the NW Catalog proxy. Go to policies and add OAuth2.0 policy to Proxy Endpoint PreFlow:

false VerifyAccessToken

Note that the operation here is “VerifyAccessToken”. This will look up the request header for the token and validate it against APIM Auth server for validity.

Hit “Update” and “Deploy” the proxy.

Go to “API Business Hub Enterprise”, in your product now you should have two updated proxies.

Also, you should have an application subscribed to this product. Please refer Publish your APIs, if you do not know how to do this.

After subscription, you should have API key and secret visible and ready for use.

Testing

Testing Individual OAuth Flow

We will need three things to test this flow:

01. API Proxy URL:
From API Business Hub Enterprise, open the “Fetch Token” service and copy the URL:

02. API Key and Secret
From prvious configuration section you can see how to get API Key and Secret.

03. Grant Type - We will use “Client Credentials” Grant here.

Using these three items, to test if our “Fetch Token” service is working or not, lets move to postman and create a request as seen below:

Hit “Send”:

We are able to get the “access_token” successfully. However, we don’t need to call this API as a service call out separately, we need to embed this “Fetch” token mechanism into our other APIs of this API Product. Let’s do that.

Using OAuth for Complete API Product

We configure OAuth for our NW Catalog API, lets see what happens if we do not provide a token now that we have a “VerifyToken” policy enforced.

As we have “No Auth”, and that we are not providing any token to our API proxy, it results into “Invalid access token” error.

Lets fix that, lets configure Authorization setting as shown below:

First Lets select OAuth2.0 as Auth method:

Lets provide parameters to fetch the OAuth Token. The value we provide here are the ones we used in “Testing Individual OAuth Flow” step, as shown below:

Scroll to the bottom and fetch new token:

Click “Use Token”.

Lets hit “Send” and see what do we get?

Voila, we are able to fetch the “Products” through Catalog service with this token Configuration now.

A few notes

Generally, one token service/API is enough per Product to facilitate an application to Authenticate all API calls of the said product.

In case you want to use your own Auth service instead of APIMs, in the step “Objective 2” of hands on configuration section, instead of providing dummy URL you need to provide Actual OAuth service API and keep the condition in rout to default. Do not change target endpoint to “None”. However, in this case “Verification” of token will be done by API Provider and not APIM.

Conclusion

Securing your APIs against misuse is an essential aspect of API security and APIM. Knowing how to secure your APIs will add to the security of your API offerings and organizational security as well.

In this blog, We are able to set up OAuth service for our APIs of an API Product. We also demo’d that without token or stale token client application will get “invalid access token” or “token expired” error.

Feel free to play around with configurations and let me know your findings in comments.

See you in the next blog.