martin.day | March 11th, 2021
Okay, so you are building or already have built some APIs that you need to protect. A key question to ask is how you will protect those APIs so that only legitimate traffic is accepted and processed. Perhaps you’ll deploy an API Gateway or perhaps you’ll embed the required security checking within the API itself.
Whichever architecture you choose, you will undoubtedly consider the benefits of utilising OAuth and its access tokens. Why wouldn’t you want to use short-lived access tokens as a means of gaining authorized access to your APIs? No need to worry about vulnerable long-lived keys which can be stolen and maliciously used over long periods. No need to worry about managing passwords and all the attendant concerns relating to compromise, never mind that they are so frequently forgotten and need to be reset. Better to let a 3rd party specialist you can trust handle those issues, allowing you to focus on what matters most to your customers - the rich functionality you can expose to them via your APIs.
Cool, decision made. You will leverage a standards-based OAuth Authorization Server (OAS) - in many cases implemented as part of an OIDC Provider (OP).
So next up, which Provider to use? Much as I think the only real choice is OneLogin, there are other providers out there so maybe it’s time to consider a PoC to give you that confidence that the product really does match up to all the Sales-speak.
You’ll want to test things such as:
- The various grant types under consideration
- Validating tokens
- Revoking tokens
- Token timeouts
- Refresh token behaviour
- Identity token behaviour
- Defining custom audience values
- Defining required custom scopes to support coarse-grained authorization to your API
- Defining custom claims to be added to the access token to support fine-grained authorization within your APIs e.g. role, group membership etc.
Some customers will have suitable test harnesses available containing clients and target APIs as necessary and so just need the knowledge to configure the OAS/OP, whereas others would also benefit from a suitable test client and target API. Whatever the specific need, time and resources to get to grips with the multiple vendor solutions are always the enemy - the video referenced in this blog is a step by step guide to achieving a successful OneLogin PoC with the minimum of fuss.
The video is organised into the following sections:
- An introduction explaining the PoC environment
- Step One - Configure the Client Application
- The video shows how to use OneLogin’s web administration utility to define the sample client application. OneLogin’s online Inspector tool will be used to act as the test client
- Step Two - Configure the API Definition
- Following OneLogin’s API-first approach, the video shows how OneLogin’s administrative APIs are used to define the sample API (the “To Do List” service).
- A pre-configured Postman collection (with environment variables) is linked below and can be downloaded to allow the configuration to be defined in moments.
- The sample API will be emulated once again using OneLogin’s online Inspector tool.
- Step Three - End to End Test
- The video shows how to perform a series of tests to prove the OneLogin authorization capabilities including behaviour of custom scopes and claims.
And that’s it - simple! Use the time saved in performing the PoC to take a well-earned coffee break!
Of course, you may want to use your own clients/APIs - in which case you should find it a trivial task to modify the postman collection to your needs. Time saved, is time well spent!