Application Programming Interfaces—better known as APIs—are the software intermediaries allowing communications between applications. For enterprises, APIs are essential to ensuring appropriate security, security auditing, and gatekeeper capabilities on enterprise networks. Yet simultaneously, APIs can appear as a complex and daunting feature to outside observers.
European customer identity and access management (CIAM) solution provider Ubisecure works to dispel this complexity in their “API Protection with OAuth 2.0: Security, Identity & Authorization for the API Economy” white paper. In it, Ubisecure also explores API protection in relation to identity.
Here are some of the key findings from the API Protection with OAuth 2.0 white paper by Ubisecure:
A Word of Introduction
To function optimally and securely, APIs need to know who is accessing their standardized communications. Throughout the years, APIs have used a variety of tools and capabilities to pass authorization and authentication data. These range from asking for additional username/password parameters, to utilizing API keys, to using an OAuth 2.0 based token support.
Often, these capabilities depend on the enterprise’s architecture:
- For the hosting servers of protected resources, API protection begins with API access requests from clients via access tokens. These require access token validation using introspection services.
- OAuth 2.0 recommends the client puts the access token in HTTP standard authorization header using a bearer scheme. OAuth 2.0 puts no other restrictions on parameters, body, content types, or other parts of the request.
API Protection and Authentication Protocols
Ubisecure identifiers four main authorization and authentication protocols in relation to API protection.
The simplest protocol is the password grant protocol, which gains access tokens from an authorization server. However, password grant protocol can come with serious security issues, including:
- Your username and password are disclosed to the client.
- There is privilege escalation because there is no authorization.
- Clients can request access tokens have a much wider scope than is intended.
Next is the authorization code grant protocol, which requires the resource owner use a user agent such as a web browser. Almost any authentication mechanism is possible via a web browser. This mitigates password grant protocol issues, as no credentials are disclosed to the client in this protocol.
The third protocol is the client-initiated backchannel authentication (CIBA). CIBA protocols enable the use of an “out of band” authentication mechanism. Authentication devices will be software running on a mobile device. CIBA also solves the issues associated with password grant protocol because no confidential information is disclosed to the Client. CIBA is suitable for the widest range of applications.
Finally, Ubisecure defines the refresh token protocol as a viable API protection system. Access tokens allow clients to make API requests for a determined length of time. But this can lead to its own security issues; if the Resource Owner wishes to allow a client access for a longer period of time, their access token can be used without more authentication requests.
Access token will have a short expiry time, a refresh token provided for API protection will have a longer expiry time. When the access token expires, the client can use the refresh token to generate a new access token which will be subject to any security changes.
You can download the full “API Protection with OAuth 2.0: Security, Identity & Authorization for the API Economy” white paper here, courtesy of Ubisecure.
Latest posts by Ben Canner (see all)
- Key Findings: The Gartner 2019 Critical Capabilities for Identity Governance and Administration - November 13, 2019
- 60 Percent of Enterprises Misunderstand Cloud Security Responsibility Sharing - November 12, 2019
- 5 Identity Management Insight Videos for 2019 (and 2020) - November 11, 2019