OAuth 2.0 is a common standard for authenticating APIs used for system-to-system access. However, since OAuth 2.0 only defines a framework, it requires support for the latest standards and access to existing authentication information is also required. So, choosing the right software is an important requirement, generating interest in OSS for authentication applications. Hitachi has released OSS-based API management solutions and made builds easier by defining standardized sequences for access to existing authentication information. The company has also played a role in the development work being done by the OSS community, providing pioneering support for the latest standards.
In the past, information systems usually had monolithic configurations that gathered all the required functions together in one location. Meanwhile, the recent rise of digital transformation (DX) is creating interest in system-of-systems configurations that provide new services by accessing multiple independent systems over a network. This system-to-system access is usually not enclosed within a single company or organization. Instead, access across multiple companies or organizations has become commonplace. Representational state transfer application programming interfaces (REST APIs; ‘APIs’) have become a widely used interface format for system-to-system access due to their ease of access. These APIs are publicly released on the Internet to promote system-to-system access. However, security problems have also arisen as APIs have ended up becoming entry points for attacks on systems. Improper API use has been responsible for a series of security incidents in Japan and other countries, so API security mechanisms that release APIs only to the systems that need them and protect the systems from attacks are a crucial requirement.
This article presents open source software (OSS) authentication and authorization technologies used for API security, and Hitachi’s work in this area.
Fig. 1—Overview Illustrating External App Access Before OAuth, and API Access with OAuth 2.0
Security risks were high before OAuth existed since authentication information was held in the external app seeking access. OAuth 2.0 enables more secure access by using access tokens to eliminate the need for passing authentication information to the external app.
Authentication and authorization done to restrict applications with API access and the users who can use them are the most basic security operations used with API releases. The OAuth 2.0 (‘OAuth’) standard defined by Internet Engineering Task Force (IETF) RFC 6749 is a common standard used as a framework for API authentication and authorization. The overview in Figure 1 illustrates how external app access was handled before OAuth existed and how API access is now handled with OAuth. To enable access between an external app and service provider in the days before OAuth, a service ID and password were usually passed to the external app, and the app was made to log into the service. Instead of an ID and password, OAuth provides security by passing a package of authorization information known as an access token to the external app. The flow is as follows: First, the external app sends a request to an authorization server to issue an access token. The authorization server authenticates the user and issues the access token to the external app if authentication succeeds. The external app then accesses the API with the access token appended. These processes do not involve passing authentication information such as an ID or password to the external app, enabling more secure access. OAuth has therefore become the de facto standard for granting external apps access to APIs.
Fig. 2—Typical OAuth 2.0 Service Configuration Example and Security Issues to Be Considered
OAuth 2.0 only defines the API authorization framework. The methods used to implement authorization are left largely up to the developer, resulting in various security issues and the need for proper implementation when OAuth is used with systems.
OAuth is just the framework used for API authentication and authorization. The methods used to implement processes conforming to this framework are largely left up to the developer. As a result, processes satisfying the OAuth standard can still be implemented improperly, creating the risk of security incidents.
Figure 2 shows a typical API-based service configuration example and the security issues to consider.
Issue 1: Improper OAuth implementation
Incorrect implementation of parameter usage in the OAuth flow is known to result in the creation of vulnerabilities that pass access tokens to attackers. New standards are routinely created to eliminate vulnerability gaps and need to be tracked. For example, a new technical specification that is backward-compatible with OAuth, known as Financial-grade API (FAPI) has recently been created and is attracting interest. FAPI is designed for use in systems requiring higher security such as financial institution business systems.
Issue 2: Improper user authentication
Since OAuth leaves the authentication method up to the developer, there are sometimes extreme cases in which authentication is handled using just an easily guessable character string. Attackers can easily obtain access tokens in this case, enabling improper API calls.
Issue 3: Improper token handling
The method used to handle access tokens issued by the authorization server is not defined, so problems can sometimes result. For example, failure to manage access token expiration can lead to the termination of API access being permanently disabled. Access tokens received by API servers can also be counterfeited or belong to other users, so a separate framework is needed to check for access token falsification and check which user each token was issued to. Failure to carry out these checks can lead to unauthorized APIs being called by attackers.
API-based services implemented without taking the points above into consideration are a continual source of security incidents, so developers are paying closer attention to security.
The authorization server in charge of issuing and managing access tokens is a very important element when implementing OAuth-based authentication and authorization. Keycloak is an OSS application that has rapidly been gaining a following in this area recently (see Figure 3). Keycloak was originally created as an authentication server implementation designed to enable single sign-on conforming to Security Assertion Markup Language (SAML) and other standards. It also has OAuth-compatible API authorization server functions. Keycloak not only supports a wide range of authentication and authorization server functions, but it also has a large number of expansion points, enabling easy customization for individual system requirements.
Since it is OSS, Keycloak offers the major benefit of having a development community that is open to anyone. It has an active development community that routinely develops functions conforming to new standards. Hitachi plays a role in this community, and has assisted extensively in developing major functions and making revisions to fix bugs and improve convenience and other features. The in-depth technical knowledge gained from these community contributions has been used to provide a support service and a design/build assistance service for Red Hat* Single Sign On, the commercial version of Keycloak. Hitachi has also used Keycloak for customer projects, creating patches to solve issues and meet demands for additional functions that have arisen as a result. These patches have been posted to the development community and included in Keycloak. Hitachi’s activities have helped make Keycloak better suited to the demands of the company’s clients (see Figure 4).
Fig. 3—Keycloak Features
Keycloak has functions enabling use as a single sign-on authentication server and authorization server for API access. Other features include support for OAuth 2.0 and other standards, social login, and access to LDAP servers or other services.
Fig. 4—Hitachi’s Contributions to the Keycloak Community and Their Use in Client Projects
Hitachi’s contributions to the Keycloak community have generated knowledge used to provide support services and assist client projects. A cycle of feedback to the community has also enabled it to refine Keycloak and provide services of higher value.
Fig. 5—Example Configuration of Keycloak-centered Secure API Management System
Shown here is an example configuration for a system that manages APIs securely using Keycloak as the authorization server. The system solves the common security issues using Keycloak and an API gateway.
Hitachi provides API management solutions that enable secure API access using a core of Keycloak-centered OSS authentication and authorization technologies. Figure 5 shows the system configuration for these solutions.
To ensure secure API access, Hitachi uses the configuration described here as the foundation for providing solutions that cover everything from upstream consulting to system construction, operation, and maintenance. Hitachi has a track record of creating API management platforms that ensure API security, and the company’s API management solutions have been used in various projects for digital services. Examples include projects for cashless services provided by financial institutions, and for mobility as a service (MaaS) in the rail transport sector.
This article has presented OSS authentication and authorization technologies used for API security, and Hitachi’s work in this area. The rise of DX is seeing API-based system-to-system access growing at a faster pace and adding to the importance of API security. Hitachi wants to provide and expand on solutions designed to make it easier to quickly create systems that ensure API security. These solutions draw on the technology and expertise assets that Hitachi has gained by developing features to conform with the latest standards and making other contributions to the OSS community.
