Header Image

OAuth 2.0 with Layer 7 Gateways, Tutorial 1: Incorporate an Existing API & Identity Provider

The Problem

An exposed API is protected by a basic username and password authentication system. We would like to expand usage of this API to external applications using OAuth for delegated authority, without having to set up an entirely new identity management system.

 

The Solution

We can use the Layer 7 OAuth Toolkit to protect this API, using multiple methods – including traditional credential types (basic auth, WS-Security UsernameToken, client certificate) and the extension of those credentials to third-party apps using OAuth 2.0.

The OAuth Toolkit provides built-in integration with an internal identity provider. Within the Layer 7 Policy Manager, we can navigate to the Authorization Server provided with the OAuth Toolkit and simply redirect the authentication assertion to point to our designated identity store – this could be LDAP, Active Directory or any other major IAM system.

We then include the “OAuth 2.0 runtime authorization fragment” in our API security policy, which will require a successful OAuth client handshake before access is granted to the API. At runtime, the policy fragment will redirect to the Layer 7 Authorization Server, which will validate the user against the intended identity store and generate a valid access token. The token will then be used to gain access to the API.

 

 

By creating two branches, we can incorporate both our original authentication mechanism (basic auth) and our new OAuth interaction path, using the same identity store.  We can also configure our API to verify the user's identity at runtime, in order to check whether there have been any contract changes within the token's lifespan.

Watch the tutorial video below for complete instructions.

 

OAuth 2.0 with Layer 7 Gateways, Tutorial 1: Incorporate an Existing API & Identity Provider

OAuth 2.0 with Layer 7 Gateways, Tutorial 1: Incorporate an Existing API & Identity Provider