Saturday, July 21, 2018

API security & tokens

Hello All. Greetings!

I have been working on API security for sometime and found it quite fascinating. So, just wanted to share my excitement and learning with you. 
It is important to understand the consumers of APIs. The consumers of APIs can be some sort of mobile app, also could be web application running on a server.

  When it comes to API security, there are multiple approaches for securing APIs :
  • api key
  • OAuth

API key:  In this approach, each client/consumer (also called as partner) is assigned an apikey. While a request for API access is made, the client sends apikey to authenticate itself. Apikeys can be thought of as passwords.
    There are few risks involved in this approach. Apart from the overhead of maintaining and managing the apikeys, the apikeys can be compromised and used by non-designated users to access APIs.

OAuth: Firstly, it is important to understand what OAuth is not for.
OAuth is not for authentication where the identity presented is compared against something which the system already has or known.
Also it is not for authorization which deals with the stuff what someone is allowed to do.

OAuth is all about delegating access i.e. mentioning that client can do things on behalf of the end users. End users are actual existing customers.

OAuth is a framework that helps building standards.
It proposes solutions for issues like password chain problem and revocation of access that are quite visible in apikey approach. 
OAuth framework, if followed properly, deals not only with API security but also ensures enterprise security and mobile/server security.
Enterprise security deals with keeping our servers safe, processes and procedures to manage our computers; such as auditing.

The cross cutting concern in any type of secutity, i.e. API security or enterprise security, is identity.
It is important to have digital identity encoded which represents who the user is.To represent that in a way that is easy to consume, JSON makes a perfect technology to do this. It has support across almost every language.

Basic usage of tokens is depicted in below diagram:



In the above diagram:
  •  user is basically the resource owner who also is the end user.
  • Client could be some moble app for example. When a request is made by user, Client approaches the Authentication Server (AS) to get a token.
  • Authentication server is the one who generally has the resource owner info and responsible to authenticate. It issues and signs the tokens. AS prompts the user for a login. Upon user login, client gets a code from AS, which is for one time use.
  • Client sends asymmetric certificate or apikey to AS to identify itself. 
  • AS responds with an access token to client and potentially a refresh token is generated and sent to client. On a high level overview of refresh token, it can be used in bootstrapping the apps and creating new access tokens.
  • In general, client uses the refresh token to generate a fresh access token on behalf of the resource owner to have a good user experience.
  •  Client presents the access token to 'Resource server' to access the actual resource or API.
There are few things associated with the tokens.

Token Profiles tell about how the token is associated with the user.

A bearer token can be considered as cash for eg. As cash can be used by anybody without a question on its source, bearer tokens can be used to access APIs without a need to validate its source.
On the other hand 'holder of key' tokens are tightly linked to their owner like credit cards.

There are several types of tokens like web service security, SAML, Custom (oracle access manager, site minder etc.), JWT (JSON Web Token).


In the modern world as mobile usage has increased drastically, so the need of APIs.Therefore there is a need of using lightweight technologies wherever possible.
JWT tokens are light weight tokens which can be passed in HTTP headers/query strings.
JWT tokens are specifically designed for mobiles and low bandwidth scenarios,

Akin to SAML tokens, JWT tokens are:
  • less expressive
  • more compact
  • are encoded with JSON & not with XML.

JWT is one of widely accepted and used tokens. It is JSON based.

It is comprised of three parts:
  • Header
  • Payload/body
  • Signature
Header respresents the algo used to generate the token. HS256, HS384 are few examples.
Payload  consists of the user data in key value pairs. Each set of key-value pair is referred as a claim.
Signature could be considered as a base64 alphanumeric value which generally changes frequently.

Below is a sample JWT token. 
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

JWT tokens are base64 encoded values.

For the above JWT token:
 Header:
 
{
  "alg": "HS256",
  "typ": "JWT"
}

Payload:

{
  "sub": "1234567890",                     
  "name": "John Doe",
  "iat": 1516239022
}

 This is about the OAuth framework and the importance of tokens.
Please post your comments. Will be happy to discuss on the concepts in order to get more understanding.
Thank you  😃

2 comments:

  1. This helps to give a quick glance of API security and tokens.

    ReplyDelete
  2. Good article Kalyan...it has info enough about tokens and security

    ReplyDelete