Alex Taylor Internet enthusiast

Okta – Day 10 – Managing API Access

O

Okta Basics Curriculum: Manage API Access with Okta
(note that I’m doing this one slightly out of order – the O365/Okta lesson is a beast so I’ll work on that one tomorrow when I have more time)

Some definitions/quick explanations to start here – I’ll be writing a lot more in depth about both of these in the near future, but for the sake of this guide…

API = Application Programming Interface
Loosely, this is a software integration that allows two different applications to talk to each other and share data. There are MANY reasons why people and companies might use APIs, but the primary reason is to enable better user experiences.

OAuth – Wikipedia says it best for this one –
“An open standard for access delegation, commonly used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords.”

Okta identifies three groups that care about/manage APIs – developers, architects, and the security team. These three groups often have conflicting opinions on how much access should be given to the APIs and the data beyond.

The key to API security is to focus on least privilege – as with any data, it is essential that administrators focus on limiting access to only users who are authorized, and that their access is limited to only the data they need, for the least amount of time necessary.

Okta covers three different API security approaches –

  1. Public APIs – no security
    Clearly the worst ‘security’ option – companies often aim for ‘security by obscurity’ in this case and assume that their public APIs will remain hidden if they don’t advertise their location, but anything on the public internet can be found and accessed with enough effort and motivation.
  2. API Keys – better security
    API keys essentially create an authentication tunnel from one application to another – good for more secure access, but they tend to be all-or-nothing and do not allow specific permissions to be set depending on the user or partner application.
  3. OAuth 2.0 – ‘best’ security (according to Okta)
    OAuth 2.0 tokens allow API designers to grant specific permissions to specific data. These tokens are also designed to expire, which helps limit and control the access.

Digital Ocean has a good in-depth technical guide to OAuth 2.0 if you’re interested in digging in further. Highly recommended.

Okta’s solution to these challenges is their API Access Management – this allows Okta to act as both the Identity Provider and the OAuth Authorization Server, so the full identity cycle is managed in one place.

From the dashboard, you can set up and configure your API Authorization Servers via Security > API

From here, you can switch to the Access Policies tab and define who has access to the API and how long that access should last.

There’s plenty more to learn about this piece of the Okta puzzle – looking forward to digging in further myself and figuring out how best to use this tool.

About the author

alexntaylor
By alexntaylor
Alex Taylor Internet enthusiast

Privacy advocate
Process developer
Product manager

Experience in information security, customer success, compliance and privacy, risk management, identity and access, and service deployment. Former teacher. Always learning.

We should hang out.