APIs (Application Programming Interfaces) are gradually becoming critical aspects of software interaction and integration over the internet, allowing fast and effective communication without
knowing how software is implemented.
The many advantages and diverse functionality of APIs have made them attractive to threat actors who intend to abuse them in many ways and for various reasons. Following a recent survey, it was observed that malicious API attack traffic surged 117% over the past 12 months, further stressing the need to adapt more efficient API security measures.
API Security can be defined as the various strategies, practices and procedures implemented to mitigate against vulnerabilities and security threats facing APIs. API security aims to protect APIs from various security threats, such as unauthorized access, data breaches, denial-of-service attacks, and more. Some of the key API security goals include; encryption, authentication, data validation, and the use of OAuth2.
OAuth2 provides a secure and reliable way to access resources using token-based secure authorization with pre-defined scopes and permissions.
What is OAuth2?
OAuth2 or OAuth 2.0 is a framework that controls authorization flow for web-based services, allowing users access to web-based resources without sharing their credentials. It provides a secure user authentication method when using APIs and lets developers and API managers establish fine-grained user permissions for web-based applications.
Why use OAuth2?
OAuth2 lets you outsource API user authentication and authorization to a third-party central identity provider (IdP). When users want to use the API, they are signed in to the IdP and granted an access token, giving them time-bound permissions to use the API. This access token is subsequently presented to other APIs, services, and applications. Other advantages of using OAuth2 are:
- IdP focuses strictly on functionality and thus provides efficiency in that regard.
- Functionality, such as federation to other identity sources or security measures like multi-factor authentication, can easily be integrated into an IdP without changing the original code base.
- IdP is a central point for analyzing, enabling, and disabling system access.
- IdP has an added security advantage because all Personal Identifiable Information (PII) is located in a central system and can be locked down in the case of an attempted breach.
OAuth vs OAuth2
OAuth and OAuth2 are both frameworks that control the authorization flow for web-based services. Unlike OAuth, which has a consumer, service provider, and user, OAuth2 has a client, authorization server, resource server, and resource owner. The major difference between the two versions is how they categorize duties and how the end user experiences them.
OAuth2 standards – Core
It is important to note that OAuth is composable and extendable. These core features are key in developing the core OAuth standards that are widely used. Each OAuth2 standard has a specific use case and does not necessarily have to be implemented simultaneously on an API. Below are the core OAuth2 standards:
- RFC 6749 and RFC 6750 – These two standards represent the most important OAuth standards. While the former covers the main authentication flow called grants, the latter covers how the access token (which represents the end product of a grant) should be used when it becomes a bearer token.
- OpenID Connect (OIDC) – OpenID Connect is an OAuth2 extension, also known as a profile, that allows access to the authentication information. OAuth2 and OIDC are often implemented together, although OAuth can function without using OIDC.
- RFC 7662 – This standard uses introspection and allows for validating access tokens by communicating with the OAuth2 server that created it. Token Introspection offers an alternative to JWTs and other self-contained token formats. Token introspection defines a protocol that inquires information about an access token intended to be used by resource servers or other internal servers.
- RFC 7519 – This OAuth2 standard is a self-contained one that uses JSON Web Token (JWT) to define a compact way to securely transmit data between parties as a JSON object. The data is typically verified and trusted using a cryptographic digital signature either using a secret key with HMAC algorithm or a public/private key pair using RSA or ECDSA.
- RFC 7636 – This standard outlines Proof Key for Code Exchange (PKCE), a security feature that aims to mitigate the risk of several API-based attacks. It is for public clients on mobile devices, designed to prevent interception of authorization code by a malicious application. PKCE is a standard recommended for clients using the Authorization Code grant.
OAuth2 standards – Specialized
Aside from the core OAuth standards, specialized ones with specific functionality exist. OAuth standards that fall under the ‘specialized’ category have no central repository that shows what IdP supports them. Thus, reading through the technical documentation before utilizing it is essential. The specialized OAuth standards include:
- RFC 8525 – Covers OAuth2 grants and mobile applications. RFC 8525 comes into place to mitigate the fact that mobile applications cannot maintain secrets and require high user input. Allowing for the authentication to be performed in an external user-agent (typically the browser) rather than an embedded user-agent (such as one implemented with web views).
- RFC 9068 – Details how to specify JWT access tokens in a standard format, making it possible for different IdPs and resource servers to interoperate.
- RFC 8628 – Details the use of an additional grant called a device grant designed for users with limited user input options, such as televisions. This allows users to log in using a secondary input device, such as a mobile phone or computer, while still allowing the original client to receive the access token.
- RFC 7591 – This standard allows for dynamic client registration, a rare feature in core OAuth2 standards. This is particularly useful for users who require as many unique clients as possible to authenticate.
How to use OAuth2 to secure your APIs
To use OAuth2 to secure your API, you can follow these steps:
- Register your API with an OAuth2 provider like Google, Facebook, or another popular provider. This will give you access to the provider’s authentication and authorization services.
- Configure your API to support OAuth2 authentication. This typically involves setting up endpoints for handling the various OAuth2 flows, such as authorization code, implicit, and client credentials.
- Integrate the OAuth2 provider’s authentication and authorization services into your API. This typically involves adding code to your API that uses the provider’s SDK or API to handle authentication and authorization requests.
- Test your API to ensure it is properly secured and that users can authenticate and authorize access to resources using OAuth2.
Conclusion
The ever-growing need to secure APIs has led to the development of numerous security tools and processes designed to do just that. The most common of which is OAuth2. OAuth2 offers standardized and specialized API security by focusing on authentication while ensuring functionality isn’t tampered with. OAuth2 can be a bit complex in its documentation and usage; it however caters to a large number of use cases and allows for continuous improvements and the development of new standards due to its composable and extendable features.