API services - Security with Apigee and Okta
Security with Apigee and Okta
Security with Apigee & Okta – In the previous articles, we introduced you to the world of APIs and then took you on the journey of API development in Talend.
Now that you’ve developed your API and are ready to expose it to the outside world, security comes into play!
Essential considerations in API development
Security with Apigee & Okta – In the previous articles, we introduced you to the world of APIs and then took you on the journey of API development in Talend.
Now that you’ve developed your API and are ready to expose it to the outside world, security comes into play!
Application Programming Interfaces (APIs) are used to communicate between multiple applications.
In some cases, the consumer may also be an external user you want to give access to your data if you make the APIs publicly available.
When developing APIs, there are a lot of things to consider carefully, some of these are:
- Security
- Performance (response time)
- Version control
- Monetization
In this article, we will focus on the security aspect of API development.
The platforms related to the security aspect 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 populate that page with the appropriate information.
Apigee
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 set security, for example, at the enterprise level.
This enforces security policies that secure all your APIs flowing through Apigee.
One can choose to use an API key generated within Apigee to ensure that only users registered within Apigee are allowed to call API endpoints.
Not only does this help you secure your API, but you can also track the usage of your APIs, who is using them and how often.
This can be useful, for example, in determining whether to deprecate a particular version of your API.
Okta
For (Customer) Identity and Access Management, we use Okta in this article.
This allows us to register users, either a customer or (internal) developer and more.
By registering them in Okta, we can validate whether the user logging in should, in this case, have access to the Global Customer Portal.
Okta is also used as an Authentication Server that 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 may be more security measures a developer can consider.
Note that steps 2 and 4 are actually a 2-step interaction: each process, for example, requesting an access token and receiving it once the Authentication Server (Okta) has authenticated the user, and the same user is authorized to consume your APIs.
This is a rather simplistic representation for complex security measures, the focus for this article is security and not the process flow itself.
Steps for user authentication and API access with Okta and Apigee
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, 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 time and expires in, say, 30 or 60 minutes.
Step 3 and 4: At this point, the customer portal is satisfied that the user is authenticated and authorized to access the resource.
This triggers the client portal to call one or more APIs to retrieve the information for this user.
Instead of calling the API endpoint directly, it goes through Apigee.
This proxy allows us to enforce more policies, for example security measures.
In the example below, you can see the different steps performed in Apigee in an order from left to right before the request is sent to the backend.
The first component is a policy to mitigate the risk of, say, a DDoS attack where your entire backend could crash and users cannot get the information they requested.
Next in line is a policy that verifies the API Key provided.
In this case, the API Key is tokenized within Apigee and therefore we can monitor traffic within the dashboards from Apigee.
After the check is successfully verified, another policy is triggered that removes the API Key from the header so that the API Key does not show up in the rest of the request.
Next 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 if the provided access token is still valid or not and if the credentials are correct.
Note that each step must be executed and return the ‘true’ flag before the next component can be executed.
The two components that come next have to do with the Okta validation policy.
Step 5: Once all security checks have been performed and found valid, the request is sent to the backend to retrieve the requested information.
This section is secured in two different ways:
- 2-way TLS
- IP whitelisting
By implementing 2-way TLS, we ensure that the backend only accepts calls from our Apigee instance and vice versa.
This is based on a key/trust store on both sides that contains certificates signed by a CA.
To ensure that traffic comes in only from trusted IP addresses, you can eventually whitelist certain IP addresses as well.
Improve your API security: Discover more with CIMT
This article contains only a few security measures one can take regarding API development.
There are many more ways to secure your API and more in depth.
Interested in what cimt can do for your business?
Feel free to contact us for more information.
Conclusion
Author
Samir M’Rabet