Revamping the OAuth/OIDC Infrastructure Without Disrupting the Existing API Ecosystem
The OAuth 2.0 (RFC 6749 and RFC 6750) specifications that are widely used today were finalized in 2012, and the OpenID Connect specifications were ratified in 2014. Leading service providers began using OAuth/OIDC in their own services shortly after the specifications were released, or even while they were still in draft form. Many have successfully built API ecosystems that include not only their own organizations, but also partners, suppliers, and general developers.
On the other hand, in environments that have been in existence since the early days of OAuth/OIDC, when there was insufficient know-how for detailed specification (profiling) of OAuth/OIDC, there are situations where old profiles are still left untouched. For example, PKCE, which is now considered preferable, was specified in 2015, but OAuth/OIDC infrastructures built before then may still not support it. Even those infrastructures that do support PKCE may continue to operate in ways that do not conform to current best practices, such as not requiring a confidential client. There are also cases where the platform complies with the OAuth/OIDC draft specifications but not the final specifications, such as differences in parameter names and acceptable formatting.
There are two approaches to improving the legacy OAuth/OIDC profiles. One is the big bang approach, where you deploy an OAuth/OIDC solution that implements the latest specifications and sunset the legacy profile. In many cases, however, this approach is not practical. The current OAuth/OIDC infrastructure supports many clients in the API ecosystem, and it’s not easy to change their connectivity specifications. The other approach is to prepare a new OAuth/OIDC infrastructure in parallel with the existing environment and host newly added clients in this separate environment. Although this approach has the advantage of phased migration, it essentially doubles the operational workload, making it practically difficult.
Authlete for OAuth/OIDC Modernization
What Authlete proposes is a third approach. This is to “modernize” of the OAuth/OIDC infrastructure, implementing the latest OAuth/OIDC specifications while preserving the existing OAuth/OIDC profiles and ensuring adaptability to future OAuth/OIDC evolutions.
The key is Authlete’s unique “OAuth/OIDC Component as a Service” architecture. Service providers can flexibly implement the front end of the OAuth/OIDC API while delegating all protocol processing and token management to Authlete. This enables a smooth transition between the existing OAuth/OIDC profiles and the latest specifications.
Latest OAuth/OIDC compliance
Authlete follows the latest OAuth/OIDC specifications, so it's always possible to build an industry-standard OAuth/OIDC infrastructure.
Coexist With Existing Custom Extensions and the Latest Standard Specifications
By integrating the Authlete API into your existing infrastructure, it's possible to extend the current unique OAuth/OIDC specifications while still being able to handle the latest standard OAuth/OIDC specifications.
Support for Any Profile
A variety of configuration options, from access token format selection to fine-grained token expiration policy settings, allow for profiling that best respects the unique specifications of the existing OAuth/OIDC infrastructure.
Flexible Deployment Options
Authlete offers three types of service systems: shared cloud, dedicated cloud, and on-premises packages, allowing service providers to choose the form of deployment based on the scope and features of their services.
