REST API Security

Basic Authentication

In this case the user sends credentials in the HTTP Headers “Authorization: Basic <Encoded-Creds>”

The <Encoded-Creds> string is a Base64 string with the format User:Password

Because of the user and password is sent in clear text using http header, it’s not a good idea to send it using http protocol. Use this instead only with ssl/https!

Another issue is that the credentials should be sent on every request

But also, every developer can access to this header.

Moreover in case of mobile app, for instance, they should be hard coded in the app code

Token based authentication

With tokens, it works like this:

  • the client asks for token to the server using credentials
  • the server checks the credentials and replies with a token
  • the client will use always that token to call protected resources
  • the server, every time the client asks for a protected resource check the validity of the token and, if it is valid, replies with the correct response

A token is, basically, an encoded string (hashed or private key for encryption)

It eliminates the need for sessions on API.

The client can send the token in the http header, query parameters, request body.

Tokens can expire and be revocated

API Key and Secret

Similar to user/password but not the same, because they are though for Applications or machines and not for humans.

API key is a API consumer, sometimes known as client key or client id.

API Secret is used by client to prove its identity.

When a client what to access to a resource using API Key and Secret, it will send the Key + a digital signature generated by the Secret.

API Key and Secret could be sent via HTTP Header, query params or request body

OAUTH 2.0

It’s a flexible authorisation framework.

It’s based on different token levels

It describes 5 methods to get the final token to access resources

User has always control of his own data (scope)

Applications/Clients need API Key and Secret.

It’s also known as Social login.

In this authorisation type we have 3 system involved:

  • User Application (the application that own user data)
  • Application Client (API Consumer)
  • Application Server (API provider)

Steps

  1. Application client asks for user authorisation to User Application
  2. User Application responds with a user token (AZ token) for Authorization granted
  3. Application Client with this AZ token asks to Application Server for Authorization to access resources
  4. Application Server looks at this AZ token and if everything is ok responds with an Access Token
  5. Finally the Application client will use the Access Token to access to the resources of the Application Server