Authentication and Authorization to Secure API’s

 

API Management plays a significant role in securing APIs. In the previous blog-post in this series we introduced you to the need of securing APIs. In this blog-post we will go a bit more into depth and discuss in more detail how Authentication and Authorization aspects can secure APIs and how this can be achieved using industry standard security design patterns. These design patterns also illustrate the usage and the role of the API Management platform in the process.

Authentication and Authorization

Both authentication and authorization are core to the security of APIs. They play different roles but together they ensure that the right legitimate consumer has the right permissions to access an API.

Industry standard security design patterns

Access Control using Oauth 2.0

OAuth 2.0 as it stands is an open standard authorization framework that provides consumers or consuming applications secure designated access to data via APIs. Before we go deeper into the OAuth integration and flows to secure APIs, let’s first understand the actors involved in the process.

Resource Owner = The human user who owns the data and would like to access the data through an application.

Resource Server = Where the user data is located and exposed via API. The API management platform sits on top of the resource server to securely expose the API. The resource owner owns the data of the API.

Client Application = The consuming application which would like to access the API via the API Management platform. The application would access the data on behalf of the end user or on its own.  

Authorization And Authentication Server = Where the user identity and access permission details are stored. Usually it would be an organization’s central identity access management system which manages the users of the organization.

OAuth 2.0 comes has two flavours

1. Two Legged Flow
   In a two legged OAuth flow, no user interaction is involved. This means the processing involves Client Application, a Resource Server and an Authorisation Server. This is applicable to the Client Credentials and the Resource Owner Password grant flow. Here the credentials are stored inside the client application.
2. Three legged Flow
   The three legged OAuth flow involves user interaction with the Authorization Server. The users interact with the Identity platform to authenticate themselves, granting permission to the client application to access the API on behalf of the user.

OAuth 2.0 requires an authorization framework to be available, which after successful authentication of the consumer, issues a bearer token or a JSON Web Token. Let’s look at different grant flows of OAuth 2.0 and how API Management plays a role in securing APIs.

Client Credentials Flow

Used in: Consuming Application to Resource API (application to application)

Flow Type : Two Legged OAuth

The client credentials flow is OAuth 2.0 – A two legged grant flow where consumers present a client_id , and client_secret to an in Bbase64 encoded format, to get an access token to access the backend API. The Authorization Server could be part of the API Management platform or could be a third party Authorization Server. Irrespective of location, the consuming application sends the access token in the header to the API management platform. The API Management platform should receive the token, verify it with the Authorization Platform and be allowed or denied access to the API. Verification is done to ensure the legitimate client is trying to access it, verifying that the client_id is the same as the registered consuming application ID in the API management platform, assuming the consuming application is registered in the API management platform and has the same client_id as registered in the OAuth 2.0 Server.

Authorization Code Flow

Used in: End user to Resource API via the consuming application (Ends user to application)

Flow Type : Three Legged OAuth

This is the most secured flow. The authorization code flow redirects the end user to the Authorization Server to authenticate himself. This is usually achieved by a client app redirect. The consumer gets a login screen where he/she is asked to provide a username and password. On successful authentication, the OAuth server issues an authorization token to the consuming application which exchanges it with the OAuth server to get the access- and refresh token. The refresh token is used to retrieve the access token once it has expired. The OAuth 2.0 Authorization Server could be part of the API Management platform or could be a third party Authorization Server. As this flow requires user credentials to be stored and managed, it is recommended to have a separate authentication platform and not have it clubbed with the API Management platform to keep the architecture simple and decoupled.

Once the consuming application receives the token, it sends the token to the API management platform to access the backend API. The API Management platform should receive the token, verify it with the Authorization Platform and allow or deny the access to the API. The verification is done with the expiry time and to ensure the legitimate client is trying to access it verifying the client_id is the same as the registered consuming application ID in the API management platform (Assuming the consuming application is registered in API management platform and has same client_id as registered in the Authorization Server).

Resource Owner Password Flow

Used in: Consuming application to Resource API (End user to application)

Flow Type : Two Legged OAuth

This is the same as the authorization code flow, however it eliminates the step to redirect users to authenticate themselves. The consuming application captures the user credentials and forwards all the necessary credentials to the OAuth 2.0 Authorization Server to get an access token. This works in scenarios where the consumer trusts the consuming application and provides a username and password to the consuming application to store and use it to get the token.

The consuming application provides the client_id, client_secret, username and password to the Authorization Server. The platform validates the details and issues an access token which will be sent to the API Management platform and in turn to the requesting client app, in order to access the backend API. The client app will then send this token to the API Management Platform in order to access the API. The API Management platform verifies this token against the Authorization Platform and allows or denies the access to the API. The verification is done with the expiry time and is done to ensure the legitimate client is trying to access it, verifying the client_id is the same as the registered consuming application ID in the API management platform (Assuming the consuming application is registered in the API Management platform and has the same client_id as registered in the Authorization Platform).

Implicit Flow

Used in: Consuming application to Resource API (End user to application)

Flow Type : Three Legged Oauth

Once again it is almost the same as the authorization code flow, however it eliminates the step where the authorization code is returned as part of the browser redirect, which is then used in the next step to get the access token from the Authorization Server.

Instead, once the users authenticate themselves successfully the access token will be returned directly to the consuming application via the browser redirect. The consuming application then sends the access token to the API Management platform to access the backend API. The API Management platform should receive the token, verify it with the Authorization Platform and allows or denies the access to the API. The verification is done against the expiry time and is done to ensure the legitimate client is accessing it, verifying the client_id is the same as the registered consuming application ID in the API management platform (Assuming the consuming application is registered in the API Management platform and has the same client_id as registered in the OAuth 2.0 Server).

OpenID Connect

Used in: Consuming application to Resource API (End user to application)

Flow Type : Three Legged OpenID Connect

OpenID Connect is an authentication framework built on top of the OAuth 2.0 authorization flow. It allows the consuming application to verify and authenticate the end user as well as to obtain basic profile information about the end user in an inter-operable manner. When authenticated successfully, the consuming application will obtain the user identity encoded in JSON Web Token (JWT). JWT tokens are concise, short and support a wide range of encryption algorithms.

In order to understand the OpenID Connect flow we need to first identify the actors involved in the process. The human user (User), the consuming application (Relaying part a.k.a RP), and the Authorization Server which will perform both authentication and authorization (Identity provider IDP).

The RP initiates user authentication by redirecting the browser to the Authorization endpoint of the IDP. The OpenID authentication request is essentially an OAuth 2.0 Authorization request to access the user’s identity, indicated by an openid value in the scope parameter. At the IDP, the user will typically be authenticated by checking if they have a valid session (established by a browser cookie), and in the absence of that, by prompting the user to login. After that the user will typically be asked whether they agree to sign into the RP. The IDP will then return an authorization code (on success) or an error code (if access was denied, or some other error occurred, such a malformed request was detected). The RP must validate the state parameter, and use the code to exchange for the ID token. On success the OP will return a JSON object with the ID token, an access token and an optional refresh token. The token can be in JWT format or can be a normal bearer access token.

RP now tries to access the backend API via the API Management platform by providing the JWT or access token in the header. We need to configure the API management platform to integrate with the IDP, so that the token can be validated, to ensure it is a legitimate user who is trying to access the right API in the backend. The API management platform uses the IDP well defined url and userinfo endpoint to validate the token expiration, client_id, scope and claims.

SAML Authentication

Used in: Consuming application to Resource API (End user to application)

Flow Type : Single Sign on Enabled

Security Assertion Markup Language, popularly known as SAML has been a widely used standard that provides the capability to authenticate, authorize, and federate identity between different entities. SAML is supported by many identity providers today and is considered the de-facto standard for providing single sign-on (SSO) and identity federation. The use of SAML as single sign-on capability allows great user experience and provides seamless access to the backend APIs via API Management integrated with the SAML supported identity provider.

There are two integrations possible

1. Use the API Management platform to provide a capability to federate to a SAML Identity provider in order to authenticate and authorize the access to the backend API.
2. Consuming applications directly interact with the SAML provider to get a SAML token and later exchange it with the API management platform to get the access token to access the backend API.

Using SAML as Identity Federation

In this scenario, the API Management platform integrates with the external SAML based Identity provider to authenticate and authorize users to access the backend API. Here the API Management platform exposes the capability to authenticate users by federating the authentication part to the identity provider.

As illustrated above, the user would like to access the backend API via the API management platform. The consuming application in this case first requests an access token to access the backend API. The API Management platform checks the validity of the client_id and then federates authentication to the SAML Identity provider. The user would login to the identity provider and is requested to grant access to the application. Once authenticated and access is granted by the user, a successful SAML authentication response is sent back to the API management platform. The API management platform would then issue an authorization code to the consuming application. The application will pass this authorization code to the API Management platform and get an access token that can be used for all subsequent requests to access the API. This type of SAML federation works for authorization codes and implicit grant types that redirect the client to a login page to enter credentials and grant permissions to the application.

Using SAML token for API Invocation

In this scenario, the API Management platform integrates with the external SAML based Identity provider to only authorized users to access the backend API. Here the API management platform offload the capability to authenticate the user and it is taken care by the consuming application. This is very similar to the OAuth 2.0 resource password grant flows.

As depicted above, here the authentication part is handled between the consuming application and the SAML Identity provider. User has been redirected to the login page hosted in the SAML Identity provider. On successful authentication, the identity provider returns a valid SAML token to the consuming application. The consuming application uses the SAML token and a valid client_id registered in the API Management platform to get the access token. The API Management platform then verifies the SAML token against the SAML Identity provider and, when verified successfully, issues an access token to the consuming application. The consuming application then uses the access token to access the backend API via the API Management platform.

Recaptcha Validation

Used in: Single page application (browser) to Resource API

Nowadays reCAPTCHA validation is gaining popularity among the single page application or in a public website or web page which requires controlled access to the backend API to display the data. An example would be to display dynamic public data to the end consumer or submitting form via API.

ReCAPTCHA validation is used to prevent the replay or bot attacks against the backend API.

ReCAPTCHA offers a nice visual challenge to trace if it’s a human user or a bot trying to access the backend API. ReCAPTCHA is integrated into website by means of javascript. It loads the challenge in the runtime and ask user to participate in the challenge. On successful participation, the website sends the result to the reCAPTCHA provider to get the response. The call to the reCAPTCHA provider done using a public key, domain name and the challenge result. On successful validation, the provider will issue a token as a success response. The webpage then makes API call by passing the token in the header of the request. The API management platform gets the token, invokes the reCAPTCHA provider with the token and a private API key to validate the token. The private API key is used to identify that the API Management platform is a legitimate user to call the reCAPTCHA validator to validate the user response token. On successful validation, backend API call is allowed to make.

API Key

Used in: Single page application (browser) to Resource API or consuming application who cannot support other security patterns.

This is the most simplified option to secure the API call. The consuming application receives a secret key once it registers in the API Management platform. This API key is then used by the consuming application to access the backend API. The consuming application sets the API key in the request header and invokes the API call via the API Management platform. The platform then verifies the API key and allows the call to the backend API.

Please note this is the least secure way to access the API and should be used in conjunction with IP whitelisting or Cross Origin Resource Sharing ( CORS).

Basic HTTP Authentication

Used in: Internal application or secure cloud based application to Resource API

A lightweight security mechanism, where the consuming application encodes the username and password (Base64 encoding) and sends it as an authorization header parameter in the request. The API Management platform decodes the string, validates the username and password and, when verified successfully, allows the call towards the backend. This can be a custom username and password issued by the platform or client_id and clientSecret.

HMAC

Used in: Internal application or secure cloud based application to Resource API

In cryptography, an HMAC (sometimes expanded as either keyed-hash message authentication code or hash-based message authentication code) is a specific type of message authentication code (MAC) involving a cryptographic hash function and a secret cryptographic key. Instead of sending the client secret, the consuming application builds a hashed key using the API URL, message payload, secretID, client_id and nonce.

• Compose the Signature. Usually the signature is composed by request url, message payload, nonce, secretID, client_id, nonce and timestamp.
• Hash the result using the SHA-1 secure hashing algorithm.
• Encode the hashed value using the Base64 encoding scheme.
• URL-encode the result.
• Send it in the HTTP Authorization message header.

Once the API Management platform receives the hashed signature, it decodes it and checks for the expiry of the message, client_id and secretID and on validation allows the call to be made to the backend API.

Join our open & innovative culture

Open, accessible and ambitious are the keywords of our organizational culture. We encourage making mistakes, we strive to do better every day and love to have fun. Doing work you love with brilliant people is what it’s all about.