Use of BIG-IP to authenticate API calls based on oAuth2.0 framework

Introduction

There is an earlier article in the series that shows how to use the NGINX Controller for Authentication of API calls (See Use of NGINX Controller to Authenticate API Calls). It is also possible to use the BIG-IP to perform authentication of API calls. This is usually the preferred method if a translation needs to occur between the authentication method being used by clients and one that is being used by the API.

Topology

Picture 1 below, represents the overall solution topology. In previous articles, I've explained how to use API security features available on BIG-IP. In this article, we'll take a look at how to use BIG-IP to authenticate calls using the oAuth2.0 framework before they get forwarded to a WAF. Order is important here. A flood of unauthorized calls may put a significant load on WAF. Therefore, it is vital to authorize calls before passing them to WAF.

Picture 1.

Configuration

A protection profile associated with a virtual server configures authentication of API calls, as well as sets up policies to secure the API. Per-request policy gets automatically created along with the profile. The policy gets most of its configuration from the profile but requires explicit specification of the provider list. The following diagram shows how all configuration pieces interact together.

Let us go through all the steps to configure BIG-IP to authenticate API calls using the oAuth2.0 framework.

Firstly, resolver. It allows BIG-IP to resolve domain names e.g. API server hostname to forward API calls to.

Next is identity provider for oAuth. In this example, Okta is used. Therefore Okta is responsible for:

Issuing JWT tokens to API clients
Issuing JWK keys to BIG-IP

As soon as OpenID URI for Okta is specified in the BIG-IP configuration, other related information is automatically retrieved, including JWK keys.

Provider list aggregates multiple identity providers. This is useful if you want to accept JWT tokens from more than one provider.

API protection profile contains primary configuration with following parameters:

OpenAPI file
Resolver
Per-request policy

Note, per-request policy gets created and configured with most properties implicitly based on options selected in the protection profile. However, identity provider needs to be configured explicitly.

Open the "Access control" tab of the profile to access a per-request policy

Per-request policy diagram shows how every incoming API call gets processed. At first BIG-IP checks identity. If a JWT token is valid, then BIGIP checks to see if the endpoint is in the allowed URL list. If both tests pass then BIG-IP forwards call towards its destination.

Click on "OAuth scope" to specify a provider list.

Specify provider list and change response to "response2". It returns the appropriate response code and authentication failure reason.

The last step is to assign the API protection profile to a virtual server. From this point, BIG-IP will verify the identity of every incoming call before forwarding it to its destination.

Following is an example of a call with a valid JWT token that gets forwarded to the destination and the response that is received:

$ curl -sv https://7a583404-3e51-4cf4-935d-f9f84f108b17.com/uuid -H "Authorization: Bearer eyJra...omitted...f8b_Q"
> GET /uuid HTTP/1.1
> Host: 7a583404-3e51-4cf4-935d-f9f84f108b17.com
> User-Agent: curl/7.54.0
> Accept: */*
> Authorization: Bearer eyJra...omitted...f8b_Q
>
< HTTP/1.1 200 OK
< date: Thu, 23 Jan 2020 19:42:33 GMT
< content-type: application/json
< content-length: 53
< connection: keep-alive
< access-control-allow-origin: *
< access-control-allow-credentials: true
<
{
 "uuid": "c9f949a6-7fca-477a-9345-8cfc61a73d7b"
}
* Connection #0 to host 7a583404-3e51-4cf4-935d-f9f84f108b17.com left intact

Following is an example of a situation where the token is invalid or the API endpoint is not in the allowed URL list. In this case, the call is blocked with an appropriate error message.

$ curl -sv https://7a583404-3e51-4cf4-935d-f9f84f108b17.com/uuid -H "Authorization: Bearer eyJra...omitted...BAD...TOKEN...rGF-w"
> GET /uuid HTTP/1.1
> Host: 7a583404-3e51-4cf4-935d-f9f84f108b17.com
> User-Agent: curl/7.54.0
> Accept: */*
> Authorization: Bearer eyJra...omitted...BAD...TOKEN...rGF-w
>
< HTTP/1.1 401 Unauthorized
< www-authenticate: Bearer error="invalid_token",error_description="Internal error during signature verification"
< content-length: 0
< connection: Close
< Date: Thu, 23 Jan 2020 19:06:35 GMT
<
* Closing connection 0

$ curl -sv https://7a583404-3e51-4cf4-935d-f9f84f108b17.com/NO_SUCH_ENDPOINT -H "Authorization: Bearer eyJra...omitted...f8b_Q"
> GET /NO_SUCH_ENDPOINT HTTP/1.1
> Host: 7a583404-3e51-4cf4-935d-f9f84f108b17.com
> User-Agent: curl/7.54.0
> Accept: */*
> Authorization: Bearer eyJra...omitted...f8b_Q
>
< HTTP/1.1 403 Forbidden
< content-length: 0
< connection: Close
< Date: Thu, 23 Jan 2020 19:44:52 GMT
<
* Closing connection 0
* TLSv1.2 (OUT), TLS alert, Client hello (1):

Hopefully this was useful. See you in comments!

Good luck!

Published Mar 03, 2020

Version 1.0