What is a REST API?

How to secure rest API

The first step in securing an API is to ensure that only api requests sent over a secure channel (formerly known as SSL) are accepted.Communicating over TLS protects all credentials and API data in transit using end-to-end encryption. 

Once the communication is over TLS,  authentication and authorization can be handled via signing based or non signing based techniques.Note that signing verifies the identity of the sender and ensures the data has not been altered in transit. 

Signing based techniques

• HMAC Authentication: symmetric signing for verifying identity and ensuring data is unaltered . 
  • This security mechanism is common in public APIs .
    • The client or application that wants to access your service will need an API Key and a Secret Key from you as the service owner. The sender uses the secret key for signing and the receiver uses secret key for verifying.
    • The sender uses the message content and shared key to generate HMAC signature.
    • The HMAC signature is passed along with message content and api key to receiver.
    • On receiver’s side,receiver determines the shared secret key based on api key .
    • Then receiver also generates the HMAC signature from the recieved message and shared secret key and compares the signatures. 
    • Authentication is successful if signatures match.
    • Payment gateway integrations often use HMAC authentication. The application owner who are integrating with pg can login to their account on payment gateway site and copy the secrety key .
• Asymmetric signing /Digital signature.
  • The sender creates cryptographic hash of the message known as a digest and then encrypting this digest with his private key to generate the signature.This signature is then sent along with the actual message.
  • The receiver decrypts the signature (signed digest) with the public key and gets the digest, creates a digest again from the message itself, and compares both. This is called verification. The receiver may have SSL certificate (which has the public key ) which can be used for verification. The sender/client application will provide his SSL certificate/public key to the the receiver (eg a bank server).
  • Note that the client and server do not share the secret key.
  • Note that for 2 way communication , both servers will exchange their public keys with each other.

Note that A JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret or a public/private key pair. Access token issued by authorization server in oauth can be a self contained JWT token. Verification of token is typically done by public key of the authorization server.The purpose of using JWT is not to hide data but to ensure the authenticity of the data. JWT is signed and encoded, not encrypted.

Note that in Oauth / OIDC signed tokens may be used. 

Other techniques 

• API keys 
  • API keys are long lived, manually managed, generated( not user chosen) , api access tokens.
  • API keys are used by automated tasks , projects and applications to
    • authenticate . The API key identifies the application 
    • authorize. The API key tells the API whether the requesting application has permission to use the API and which of the API’s services it may access. Typically an API key grants less access than the user account it is created for.
  • An API key cannot be used for logging into a user interface ie API keys are not used for user authentication.
  • As opposed to api keys , user id / password is typically used by users/person to authenticate.
  • API keys are typically randomly generated (not created by user) by the back end system at the request of a user/application owner and bound to user's account.The user would login to his account in the API owners website and request for generation of api key . Since they are generated, they have high entropy and are not easy to guess  . As allready mentioned they are used as authentication and autorization token by apis of the back end which has issued it. Those APIs are called over a network, typically with HTTP requests.   An example would be search service like algolia where a client can go to his account and copy api keys. API key can have read acccess to read or write  or both. Eg algolia provides api key with read access which can be used in javascript and api key with read/write access which should only be used on the serverside. 
  • API Keys are independent of the account’s master credentials and can be revoked and created at will . This is valuable for key rotation strategies, i.e. requiring a new key per month, or removing keys (if compromised)
  • The back end system which is generating access token some times shows the api key only once . This has the advantage that while storing the api  token , the back end does not actually store the api token but a salted hash of the api key. Typically passwords are stored in this faishon.
  • API key cannot be put in untrusted environment, eg source code, api key being present in mobile app. API key should be added to request headers , not request URL. Commonly x-api-key header is used. Alternatively Authorization header can also be used. 
  • API keys can be revoked.
  • M2M apps use the OAauth Client Credentials Flow , in which they pass their Client ID and Client Secret to authenticate themselves and get an access token which can be used to make an api call to resource server .
• Functional / technical user accounts -  These accounts do not represent a person. User accounts are created in back end and used for automation or client program/ server program interaction (eg connecting to database). The issue is human created passwords are not strong enough and hence often mandatory password change policy which creates an issue of reconfguring the client. While backends can be accessed via userid/password by client applications API keys have some advantages like higher entropy.
• Cookie based authentication.
  • In simple login flow , once the user provides userid/password to authenticate, the server adds a session cookie in response headers which the client keep returning to server in reqeust headers with every reqeuest to server.