Oracle Developers
Published in

Oracle Developers

How to Use Azure AD to Secure OCI API Gateway With OAuth and JWT

Azure AD is a popular identity and access management (IAM) service in Azure. It’s cloud-based and can serve as OAuth 2.0 IdP, making the SSO across multi-cloud easy and fluid. OCI API Gateway is a rock-solid API management solution for securing and controlling APIs in OCI. API Gateway can use Azure AD OAuth capabilities to secure and authorize API endpoints. How to set up OAuth SSO between Azure AD and API Gateway in OCI based on JWT? What if JWKS keys are not compatible between Azure AD and API Gateway? How to configure API Gateway in OCI to use Azure AD-issued JWT? Continue reading and find it out.


  • You have access to OCI and Azure tenancies.


In the multi-cloud era, it’s preferred to use distributed components across different hyper-scale clouds. This example will ensure that Azure AD OAuth IdP protects API deployments in OCI using the JWT tokens and OAuth client credential flow. The flow is typically easy to use since it requires exporting (1) JWKS keys from Azure AD IdP and importing them into OCI API Gateway. The client application then invokes Azure AD IdP to (2) issue JWT using client credentials and grabs the JWT from the response. Finally, the client application supplies JWT with the (3) request against protected API Gateway resources in OCI. Three mentioned steps are depicted in the architectural sequence below.

Ideal architecture

Due to certain limitations in JWKS related to the absence of alg field from the keys, we need to develop the JWKS Adapter component in OCI, acting as a proxy for the sequence (1) above. JWKS Adapter modifies JWKS on the fly by adding the required alg field, setting it up to RS256. In addition, JWKS Adapter reduces the total size of JWKS by removing x5c from the key. JWKS Adapter is built using Functions, and API Gateway is OCI.

Target architecture with JWKS Adapter component

The target architecture is comprised of four main components:

  • (A) Active Directory OAuth IdP [Azure]

JWKS Adapter (B) plays the role of a reverse proxy between © Secured API and (A) Active Directory OAuth IdP. The sequence starts with API Gateway (3) retrieving adapted JWKS from another API deployment, serving as a facade for the function. API deployment (2) invokes Functions, which (1) invokes Azure JWKS and modifies it on the fly. When the message is returned to the original requestor © JWKS Adapter, it’s a set of modified JWKS from Azure, ready to be used in API Gateway.

Ensure to follow the next steps:

  1. Configure (A) Azure Active Directory OAuth IdP

1. Configure (A) Azure Active Directory OAuth IdP

Open Azure Active Directory the Azure Console. Register a new Application by selecting App registrations from the left menu and pressing New registration button.

Give the application friendly name, select the option Accounts in this organizational directory only (Default Directory only - Single tenant) and press Register.

Take note of Application (client) ID, since we will use it as a credential in token generation API.

Select Certificates & secrets from the left menu and press New client secret button.

Enter a short secret description and pick the expiry option. By default, the expiration of the secret is set to 6 months. The secret will go in pair with Application (client) ID from step 3. Finally, press Add button.

Take a note of secret by copying Value field.

Select Token configuration from the left menu and press Add optional claim button. Then choose Access token type and select aud claim. Press Add button to complete the action.

Return to the Overview from the left menu, press Endpoints button and copy the OAuth 2.0 token endpoint (v1) URL, which will be used for the issuance of JWT tokens.

2. Build and Deploy (B) JWKS Adapter Using OCI Function

Create an application for JWKS Adapter Function by pressing Create application button.

Ensure you have the proper VCN configured and ready to host the JWKS Adapter Function. Enter a name (e.g. jwks-adapter) and press Create.

When the Application is created, select Getting started from the left menu and follow Setup fn CLI on Cloud Shell guide. Follow the steps from 1 to 7. You will need to launch Cloud Shell by pressing the button or selecting the icon in the upper right part of the page.

Keep the Cloud Shell open and clone the adapter function from the GitHub

git clone

Enter the cloned repository and deploy the adapter Function to the Application created in step 1. Make sure the --app parameter is equal to the Application name.

fn -v deploy --app jwks-adapter

Test the freshly deployed function by invoking

fn invoke jwks-adapter azure-jwks-transformator

If it’s properly configured, it should return something similar to:

ivan_delic@cloudshell:~ (eu-frankfurt-1)$ fn invoke jwks-adapter azure-jwks-transformator {"keys":[{"kty":"RSA","use":"sig","kid":"nOo3ZDrODXEK1jKWhXslHR_KXEg","x5t":"nOo3ZDrODXEK1jKWhXslHR_KXEg","n":"oaLLT9hkcSj2tGfZsjbu7Xz1Krs0qEicXPmEsJKOBQHauZ_kRM1HdEkgOJbUznUspE6xOuOSXjlzErqBxXAu4SCvcvVOCYG2v9G3-uIrLF5dstD0sYHBo1VomtKxzF90Vslrkn6rNQgUGIWgvuQTxm1uRklYFPEcTIRw0LnYknzJ06GC9ljKR617wABVrZNkBuDgQKj37qcyxoaxIGdxEcmVFZXJyrxDgdXh9owRmZn6LIJlGjZ9m59emfuwnBnsIQG7DirJwe9SXrLXnexRQWqyzCdkYaOqkpKrsjuxUj2-MHX31FqsdpJJsOAvYXGOYBKJRjhGrGdONVrZdUdTBQ","e":"AQAB","alg":"RS256"},...]}

Find your API Gateway from the OCI menu, select Deployments, and press Create deployment. This will expose our adapter Function to be invokable.

Fill the Name and Path and press Next.

Leave the deployment with No Authentication, since it will only serve to proxy and modify Azure JWKS and adapt it to API Gateway's expected format. Press Next to proceed.

Create a Route, define a Path and Methods. Choose Single backend with Oracle functions type. Select Application and Function deployed in the previous steps.

Review the deployment and press Create.

Wait until Deployment is in Active state and copy the Endpoint.

Use Postman or a similar tool to test the endpoint. It should retrieve Azure JWKS with modified values. Paste copied endpoint and suffix it with Route path from step 10.

3. Deploy © Secured API With API Gateway and JWT

Find your API Gateway from the OCI menu, select Deployments, and press Create deployment. We will create an API secured by JWT.

Fill the Name and Path and press Next.

We will protect the API with JSON Web Token (JWT). Under the Authentication step, select Single Authentication. Select JWT token location to Header and define header name to Authorization. Use Authentication scheme Bearer. Press Next to proceed.

Define Allowed issuer and Allowed audience. Since we used v1 token API, Allowed issuer should be set to{tenant-id}/. Replace {tenant-id} with your Azure tenant ID. Allowed audience should contain aud claim value, and by default, unless explicitly set, it is 00000002-0000-0000-c000-000000000000.

For Public keys, make sure to select Remote JWKS and enter JWKS URI to match deployment of JWKS Adapter Function

Create a Route, define a Path and Methods. Choose Single backend with Stock response type. Define a simple Body and Status code. Press Next to proceed.

Review the deployment and press Create.

Wait until Deployment is in Active state and copy the Endpoint.

Use Postman to retrieve the JWT token from Azure AD. Enter token API URL{tenant-id}/oauth2/token, while replacing {tenant-id} with your Azure tenant ID. Send a request and copy access_token value.

Finally, use Postman to test the secured API endpoint. Paste copied endpoint and suffix it with Route path from step 6. Add Authorization header, use the Bearer scheme, and paste the JWT token issued in the previous step.

That’s it. You have secured API Gateway deployment with Azure AD JWT.

If you’re curious about the goings-on of Oracle Developers in their natural habitat, come join us on our public Slack channel!

If you haven’t already done so, you can sign up for an Oracle Cloud Free Tier account today. It’s not necessary to follow along to with this post, if you’re curious about how to get started with OCI, signing up is the first step!



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Ivan Delić

I’m a solution engineer, developer, and architect with strong technical and social skills. My specialties are application development, architecture, and cloud.