Security with Apigee and Okta – In the previous articles we introduced you to the world of APIs and after that we took you on the journey of API development in Talend. Now that you have developed your API and are ready to expose it to the outside world, security comes into play!
Application Programming Interfaces (APIs) are used to interact between multiple applications. In some cases, the consumer can also be an external user whom you want to provide access to your data if you have the APIs publicly available. When developing APIs, there are a lot of things that you should consider very carefully, some of these are:
- Security
- Performance (response time)
- Versioning
- Monetization
In this article we will be focusing on the security part of API development. The platforms related to the security aspect that are used in this article are Apigee and Okta. The use case is that there is a Global Customer Portal that uses APIs to retrieve the data that the user requests. For example, the user logs in and wants to see the Management Dashboard, the Global Customer Portal then calls one or more APIs to fill up that page with the correct information.
Apigee is an API management platform (gateway), where one can for example create a reverse proxy API to oversee all API activities within one API Management layer. This also helps to setup security for example on enterprise level. This enforces security policies that secure all your APIs that flow thru Apigee. One can choose to use an API key that is generated within Apigee, to ensure that only users that are registered inside Apigee are allowed to make calls to the API endpoints. This does not only help you secure your API, but you can also keep track of usage of your APIs, who is using it and how often. This can for example be helpful to determine whether you can deprecate a certain version of you API.
For (Customer) Identity and Access Management we will use Okta in this article. This allows us to register users, either a customer or (internal) developer and much more. By having them registered in Okta we can validate if the user that is logging in is supposed to have access to the Global Customer Portal in this case. Okta is also used as an Authentication Server which does the minting of OAuth2 access tokens. With this functionality it also provides an endpoint for validating the same token against your Okta organization.
The following diagram explains the flow from the user to the AWS Instance where the API is running. Keep in mind that there can be more security measures that a developer can consider. Please note that step 2 and 4 are actually a 2-step interaction: each process, for example requesting an access token and receiving it if the Authentication Server (Okta) has authenticated the user, and the same user is authorized to consume your APIs. This is a rather simplistic view for complex security measures, the focus for this article is the security and not the process flow itself.
Step 1: The user logs into the Customer Portal with a username and password.
Step 2: The Customer Portal validates these credentials and requests an OAuth2 access token for this user. If the credentials are correct and the resource the user is trying to consume is allowed for this user, then Okta generates an access token that can be used during the session on the Customer Portal. Typically, an access token is generated for a short amount of time and expires in for example 30 or 60 minutes.
Step 3 and 4: At this time the customer portal is ensured that the user is authenticated and authorized to access the resource. This triggers the Customer Portal to call one or more APIs to retrieve the information for this user. Instead of calling the API endpoint directly it goes thru Apigee. This proxy allows us to enforce more policies, for example security measures. In below example you can see the different steps that are being executed in Apigee in a sequence from left to right before even sending the request to the backend.
The first component is a policy to reduce the risk of for example a DDoS attack where your entire backend can crash and result in users not being able to get the information they have requested. Next in line is a policy that verifies the provided API Key. In this case the API Key is minted within Apigee and therefore we can monitor traffic within the dashboards from Apigee. After the check is verified successfully another policy kicks in that removes that API Key from the header so that the API Key does not show in the rest of the request. After that there is a policy that validates the OAuth2 access token and the Okta credentials in Base64 encryption with Okta. It makes a service callout to the Okta endpoint for validation, this way you can check whether the provided access token is still valid or not and whether the credentials are correct. Note that every step must execute and return the ‘true’ flag for the next component to run. The two components that come after are related to the Okta validation policy.
Step 5: When all the security checks have been executed and found valid the request gets sent to the backend to retrieve the requested information. This part is secured in two different ways:
- 2-way TLS
- IP whitelisting
By implementing 2-way TLS we are making sure that the backend only accepts calls from our Apigee instance and the other way around. This is based on a key/trust store on both ends that contain certificates signed by a CA. To ensure that traffic only comes in from trusted IP-addresses you can ultimately also whitelist certain IP-addresses.
This article only grasps some security measures one can take related to API development. There are much more ways to secure your API and more in depth.
Interested in what cimt can do for your company? Feel free to contact us for more information.
Contact