REST API Security
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
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)
- Application client asks for user authorisation to User Application
- User Application responds with a user token (AZ token) for Authorization granted
- Application Client with this AZ token asks to Application Server for Authorization to access resources
- Application Server looks at this AZ token and if everything is ok responds with an Access Token
- Finally the Application client will use the Access Token to access to the resources of the Application Server