API Security

In today’s digital world, more and more customer interactions and transactions are occurring via the web and mobile channels, where predominantly APIs are been used for Information Exchange. This enables modern enterprises to break traditional barriers and expose their on-prem and cloud-based digital assets to the outside world in a secure manner.

These APIs provide a consistent method for those external entities such as web, SPA, or mobile clients to access their enterprise digital assets, whether they are located on-prem or in a cloud infrastructure. The key challenge for enterprises in this digital journey using API is ensuring this information exchange is occurring with the right consumer with the right privileges. Therefore, authentication and authorization play a critical part in this digital journey, and this has matured over the period with the rebellious requirements of the modern web, SPA, and Mobile clients.

OAuth 2.0 and OpenID Connect are fundamental for API Security, and they offer a framework for effectively handling both authentication and authorization requirements for these modern Web, SPA, and Mobile applications. While there are a ton of material on these protocols and framework, my focus today in this blog is to ensure these enterprises procure the right provider to secure their consumer’s digital journey.

OAuth2 and OpenID Connect (OIDC) Providers

Choosing the right provider is crucial for these enterprises in ensuring a secure digital journey for their clients. Given the current trend, these providers:

Should support any number of identity stores implemented by LDAP, AD, SSO, Kerberos, SCIM user directories, or Federated Identity Providers
Should have the ability to VALIDATE and INTROSPECT the issued tokens
Proper Session Management and Content management capabilities
Should support both 2-legged and 3-legged grant types
Should have the ability to REVOKE issued tokens due to secondary scenarios
Should have the ability for “Continues Access Evaluation” and manage the issued token accordingly
Should provide a management console for managing clients
- Register, manage, and revoke clients
- Manage, revode, and regenerate client keys:
  - Expired client secret
  - Custom client key
Should provide APIs to review and manage both registered clients and client keys for dealing with things programmatically as needed as well as batch requests
As an OIDC Provider, it should have the ability to customize “Well-known”, “UserInfo” and “JWKS” endpoints as needed

Grant Types – Flows to Acquire Tokens

Apart from the features and capabilities listed above, “Grant-Type” is another necessary detail that Enterprises must consider while deciding on the OAuth2/OIDC provider. Grant-type is the flows leveraged by clients (Web, SPA & Mobile apps) to acquire the access tokens, which provides the necessary authorization to access their protected resources. As a provider, they may offer several types of grant types, but organizations need to ensure that they have all essential Grant-Types that would satisfy their current and future requirements including the ability to customize their own before finalizing. Below is the list of major ones for reference:

Authorization Code

Auth code flow occurs when the user sign-in to applications by using third-party authentication providers like Google, Facebook, GitHub, etc., or your own OAuth Server like Layer7. This is the most common flow to authenticate and authorize client agents to access protected resources. Auth Code flow securely exchanges the code for an access token using a redirect URL, making the token invisible to the user.

Proof Key for Code Exchange(PKCE)

PKCE is an extension to our standard Auth code flow, it is a security-centric grant type, where client agents need to prove to the provider that the given code is authentic (as part of the token exchange), thus the main concept of PKCE is proof of possession. This flow includes both code challenge and Code Challenge Method as part of the authorization, where auth server persists the information, and the Code verifier as part of the Token request, where the auth server compares the value and then issues the Token.

Mutual-TLS Client Authentication (mTLS)

In the mTLS client Authentication flow, both the authorization server and any client that wants to be authenticated should possess its own certificate. It is a certificate-bound access token that ensures that only the entity that is in possession of the private key corresponding to the certificate can utilize the token to access the associated resources. In other words, when an access token is issued to the client, it is associated with the client certificate, so when the client is trying to access a protected resource using that access token, it should present the same certificate along with the request to be successful. This process makes this flow secure and mitigates the problem of stolen access tokens.

Client Credentials

Client Credentials grant type is used by the client application to acquire an access token for accessing protected resources. This is outside the context of a user, meaning, the client credentials flow is used when access is requested on behalf of the application, not a user.

Refresh Token

Refresh Token is issued as part of successful authentication (and authorization) by the Authorization server. For the same reason, it is essentially client credentials, so whenever the access token is expired or if we need to obtain a supplementary access token with specific scopes, we may leverage this refresh token.

SAML 2.0 Bearer Grant

OAuth 2.0 SAML grant type is very much like our Refresh Token grant type, where the app is already acquired the necessary approval. The SAML assertions will be passed as part of the /token request, where the SAML assertion will be processed, and the requested access token will be issued (based on prior approval). In this grant type, the client does not require refresh token nor need to store them. Also, no need to pass the client’s secret as part of their token request.

JWT Bearer Grant

JWT Bearer Grant type is very similar to SAML Bearer Grant Type, where the application requires prior approval or should be connected app. This way any authorization server can issue access tokens to the connected app, without the need to send any confidential information like client credentials. So JWT Bearer Grant or JSON Web Token Bearer is leveraged by a trusted app to get access to secured resources without authorization.

Device Code Grant

Device Code Grant is more useful for IOT like devices, where it is not easy for user interaction or data entry. In other words, the Device Code Grant is suitable for all those devices with input-constrained and needs to access protected resources.

FAPI 2.0 Complaint Provider

Enterprises that need securing and protecting APIs in highly sensitive or high-value scenarios, then they need to ensure their provider is FAPI 2.0 Complaint. As per specification [RFC6749] FAPI is an API security profile based on OAuth 2.0 Authorization server, which may contain the specifications for protecting APIs in high-value scenarios. Even though this was initially focused on financial grade applications, it is generally applicable for protecting APIs with highly sensitive data.

Conclusion

With the growing app economy, there is an increased focus on digital transformation. And APIs are becoming a key enabler in establishing secure communication with applications and Microservices. Layer7 API Management OAuth Tool Kit fulfills the demand of today’s enterprise in both securing and protecting their digital assets (Web, SPA, and Native/Mobile applications and microservices) with OOTB capabilities and features.

As I have shown above, Layer7 API Management OAuth Tool Kit provides you with OAuth Manager and Test Clients along with Server-Side APIs for automation and administration. Also, it is supporting several OOTB grant types including the option of creating a custom grant type, please refer to the technical documentation for further details in this regard. With the latest release of v4.6.1, it is now FAPI 2.0 compliant and supports both baseline and advanced security profiles. Layer7 OAuth tool kit along with API Gateway becomes a powerful combination for API Security.

If you don’t have Layer7 as your platform, you need to ensure your OAuth2/OIDC provider supports all the above-mentioned features and capabilities along with those grant types discussed above to support your current and future API Security and protection requirements for both your Web, SPA, and mobile/native applications and backend Microservices.