Security is one of the most critical requirements when we’re talking about developing modern APIs. But implementing this requirement can also be a straightforward task — today, we’re going to walk through a modern approach using the OpenID Connect mechanism to secure an API deployed in Anypoint Platform.
What is OpenID Connect?
OpenID Connect (OIDC) is an open standard and authentication protocol that works on top of the OAuth 2.0 protocol, which allows clients to verify the identity of the end-user based on the authentication performed by a server, instead of OAuth which is mainly focused on the authorization.
OIDC as a standard has several implementations; one of those is Okta, which, with the Okta API Access Management solution, provides an elegant way to set up an authentication mechanism on top of our APIs.
As of now, Anypoint Platform supports Okta and other providers as OpenAM or PingFederate to act as an External Identity to manage and authenticate client applications that access to our APIs secured via policies.
In this post, we are going to walk through the process of setting up Okta as the identity provider to secure an API published in Exchange using the OIDC standard and the OpenId Connect access token enforcement policy.
Prerequisites
- An Okta account: you can get an Okta Developer Account here.
- An Anypoint Platform account: register for your trial account here.
- An API implementation deployed in the API Manager.
- REST Client, like Postman or Advance Rest Client.
This post consists of three main parts, the setup of the Okta authentication server, the definition of the OpenID client in Anypoint Platform, and the securing process of an existing API in Anypoint Exchange with an OpenID authentication token.
Okta Setup
If you already have an Okta Application and Authorization Server, jump into the Step below: External Identity Management in Anypoint Platform.
Creating a new Web Client Application
After you’ve created the Okta developer account, log in into the platform, and in the dashboard create a new application.
Select a new Web Application, as the application we’re going to work with is a Java Web one.
In the following form, you could have changed the application’s name, but for this example, we’re going to be focused on the security process rather than these trivial details.
Also, check the client credentials grant type (you can learn more about the grant types here), as we are going to use these two different types: client credentials and authorization code.
Notice that we’ve set the permission group to “Everyone” (it should be set by default), so all the users registered on our organization can use it.
Creating a new SSWS Token
Next, create a Single Sign-On Web System token (SSWS) as below:
Warning! Read the whole page before doing anything else. Give this token the name of SSWS, and after being created successfully, copy and paste it somewhere, this is the only time that we will be able to do it.
With this, we’ve completed the Okta Setup.
Retrieving authorization server’s metadata
As the last step of this Okta setup, you need the authorization server’s metadata, and if you are using a developer instance, there should be one already provisioned with the name “default” (which should suffice for simple use cases), that we can access from the menu API > Authorization Servers.
Click on the default hyperlink to access the server settings, and within this page, you can access to the Metadata URI, click on the link to see all the available endpoints from the server.
At this current endpoint, you’ll see some important endpoints as the /authorize, /token, and (if we scroll down to the bottom), /introspect. All this information is needed for the next step, so save this URL.
Anypoint Platform Setup
Setting up a new external identity in the access management of Anypoint Platform
Log into your Anypoint Platform account, and go to the Access Management tool, either from the home page or through the hamburger menu.
At this point, you’ll be prompted with the external identity form to enable the dynamic client registration, all the information required can be found in the previous step Okta Setup. Change the values accordingly with your account.
- Issuer: https://dev-299801.okta.com/oauth2/default
- Client Registration URL: https://dev-299801.okta.com/oauth2/v1/clients
- Authorization Header: SSWS 00QCjAl4MlV-WPXM…0HmjFx-vbGua (SSWS is the prefix for Okta, as Bearer is for other providers)
- Client ID: 0oaoxbwr1XkRyamwc356
- Client Secret: xFBFrrFcyeuGVXBYhrXOSTeAzTzmXYSRPc-_Xfhp
Both can be retrieved from the general settings tab of our application at the Okta’s dashboard:
Click on Applications > App’s name (My Web App).
In the settings panel, click on the general tab and scroll to the bottom where we’ll find a section named Client Credentials to copy the client ID and client secret, values.
The remaining 3 URLs can be found at the Authorization server metadata’s endpoint.
- Authorize URL: https://dev299801.okta.com/oauth2/default/v1/authorize
- Token URL: https://dev-299801.okta.com/oauth2/default/v1/token
- Token Introspection URL: https://dev-299801.okta.com/oauth2/default/v1/introspect
If you have questions about any of these fields, you can take a look at the official documentation here.
The Dynamic Client Registration form should look like this:
Now, let’s click on save, and with this, we’ve completed the Anypoint Platform Set Up.
Secure API with OIDC
Assuming that we already have an API specified and deployed into CloudHub, we can now go and apply an open Id policy (it’s provided out-of-the-box) to secure our API through the Okta authorization server, that we created a few steps before.
For illustrative purposes, I’ve created a demo API that returns a mock JSON response, and deployed it into CloudHub: http://helloworld-andresc-mulesoft.us-e2.cloudhub.io/users
Now, we have to set up the policy; for that, let’s go to API Manager and select the required API, click on Policies > Apply New Policy > Select OpenId Connect access token enforcement policy, select the appropriate version (e.g. 1.2.0), and press the blue button -configure policy-.
Applying the OpenID Access Token Policy
In the next screen, just leave the values by default, there will not be any scope specified at this moment:
At this step, our API is secured. Now if we access it through the URL, we’ll see an authorization error:
Requesting access to the API
Now, that the API is secured and published in Exchange, we can request access, and a new client application will be registered in the Okta instance, this is possible due to the configuration of the dynamic client registration that we did before.
Click on create a new application.
In this step, select the checkbox for the authentication code grant. This grant is used when we’re establishing a system to system communication/authentication.
We’ll see two important things: the first one is that a new application is automatically registered in the Okta instance.
Secondly, in Anypoint Platform, we’ll get the client_id and client_secret required in order to get the access code.
Testing the API: How to get the access token
Using a REST client like Postman, we can request an access token going to the Authorization tab.
Press the button “Get New Access Token,” and fill the details with the Okta application automatically registered in the previous step.
In Postman, we can attach the token in the same tab, and we can get the resource.
In the same way, after getting the access token, we can append it as a request parameter, thus:
With this step, we’ve completed the process of securing an API through an OIDC external authorization server and requested successfully accessed it, and consumed it with Postman and Chrome.
To learn more about API security, check out our whitepaper, API security best practices.
