Making OAuth and OIDC Accessible to Developers

Simplifying Application Development Security 

Security is an integral and often challenging component in application development. Developers focus on the functionality of the frontend and backend, but they may be unaware of potential security design flaws in their implementations and APIs. OAuth and OpenID Connect (OIDC) provide a standardized security framework for protecting applications.

Authlete is a service solution that streamlines development of security components. Software Engineering Daily’s Gregor Vand recently spoke with the Principal Architect at Authlete, Justin Richer,  to discuss common authorization, identity, and security challenges, and the solution landscape. You can find their full conversation here.

The Gap Between Developers and Security Professionals

Developers’ interest, and often their time, is focused on adding functionality to applications. The security of these systems can sometimes seem obtuse, since security is a specialty that many are not totally familiar or comfortable with. As a consequence, design problems often emerge as applications are built.  

“Sometimes, the security team shows up and says, you can’t connect everything together because that’s not secure,” explained Authlete’s Justin Richer. Security professionals often start with the desire to lock the system down and protect confidential information. Consequently, security gets in the way of the application developer, who wants to provide functionality to connect data, people, and processes. The functionality and security viewpoints may possibly clash because their goals are different. 

Security Systems Have to be Collaborative

As a result, a fresh outlook and approach are needed. As Gregor noted, “the juxtaposition of collaboration and security does not initially sound like they can coexist, but they have to.” 

Humans use the security solutions, and often how people interface with these products is not in the way that vendors designed or even considered. So, enterprises must create security checks that keep information secure but do not prevent people from completing their work, and this is often a difficult balancing act. 

What are OAuth and OpenID Connect?

Two key building blocks of modern application security are OAuth, from the IETF, and OpenID Connect, from the OpenID Foundation. Each of these standards plays a key role in ensuring security, but the specifications can be challenging for developers to work with.

While often thought of as an authorization protocol, OAuth is fundamentally a delegation protocol. “OAuth excels whenever you have multiple systems and need to provide an abstract security layer,” noted Authlete’s Justin Richer. In applying a delegation protocol, a user possesses a set of system rights that perform certain tasks, such as the ability to access a record or update certain metadata. Users delegate specific subsets of their rights to applications that perform them on their behalf. How does OAuth accomplish this? OAuth creates an artifact called an access token that encompasses not only the end user’s rights but also the identity of the delegated software.

Here are the steps in the delegation process:

The OAuth delegation process, including the resource owner (or user), client software, authorization server, and protected resource (the API or service being accessed).
The OAuth delegation process. Image from OAuth 2 In Action by Justin Richer and Antonio Sanso. Manning Publications 2017. Used with permission.

A user, known as the Resource Owner (RO) in OAuth terminology, has access to an API, known as the Protected Resource hosted on the Resource Server (RS). The RO wants a piece of software, known as the Client, to act on their behalf at the RS. The RO can authenticate to the system to prove who they are and that they have access, but we don’t want the RO to give those credentials to the Client. OAuth provides an Authorization Server (AS) to facilitate the RO giving the client delegated access, through the use of an access token. The access token represents the combination of all the parties in the OAuth protocol and the access being given, and it can be used by the Client to call the RS.

The OAuth standard simplifies typical API integration work by allowing the Client and RS to never deal with the user’s credentials, and it allows the user to be very deliberate about what kinds of access they want to give the Client application. 

The second component, OpenID Connect, works with OAuth. OAuth enables users to securely delegate certain rights to pieces of software, but OAuth does not tell the software who the user is. OpenID Connect works by allowing the user to delegate their own identity information to the client software from the AS, which becomes an Identity Provider (IdP) in OIDC. The IdP provides information about who the user is alongside the access token from OAuth. “Let’s say an app needs all of the extended profile information, such as address, email, and other personal data. A developer writes an API call to do that. That API call is protected by an OAuth access token and it’s the same OAuth access token that I got when I made the call that said who is the user. That access token could also be used for many other functions: getting their calendar information, looking at their bank account history, checking their health record, or any other type of transaction. All these features are possible, but developers need to create them in order to use them.” 

A Hosted Security Solution 

When building out a protected system, developers need to have dedicated components like the AS to provide key security functionalities. Building an OAuth AS and an OIDC IdP is a formidable task, but many deployments need a level of flexibility and power that only building can provide. But how could you go about building such an important security component?

Authlete is a unique product because it’s a hosted service that provides OAuth and OpenID Connect support functions. What is different from other services is that Authlete does not host the entire platform that handles user authentication, accounts, or attributes. Instead, it supplies support for the OAuth and OpenID Connect protocol pieces where and when they are needed. 

“Authlete really shines in the space where developers want to build out something custom and have it run in their environment and programming language,” explained Authlete’s Richer. A developer needs to build an IdP or AS. A request comes in to the developer’s implementation, say a token endpoint request or an authorization endpoint request. The software then calls the Authlete service, which examines the request: Is this request formed correctly? Is everything formatted properly? Which extensions are valid? What should the response be?

Authlete provides developers with an SDK that features an OAuth library they can call and use as needed, but instead of being a static library, “the solution is backed by a live service,” said Authlete’s Richer. Authlete stores the protocol state, which allows it to manage data over time.  It handles tokens, keys, and other information so the application developer doesn’t need to account for these directly. Authlete also provides libraries to ease integration, “our libraries turn around and they call the right endpoint with a properly formatted REST request. The API itself is really straightforward.” Some of Authlete’s largest customers have been able to take advantage of this by integrating directly with the API without needing to use an SDK, which wasn’t available in their preferred development platform.

In essence, the developer builds their own authorization server. They provide the application rights and privileges and the OAuth and OpenID parts. Therefore, they concentrate on shipping the features of their application or service. The Authlete service provides only the security layers that matter to their applications.

As a result, instead of taking an off-the-shelf software project and building their own security system on top of it, developers have a world-class system on which they build out their own customized functionality. Nor do developers need to give over all control to a fully hosted service. With the Authlete product, customers retain the control and flexibility that a custom solution provides but don’t have to become experts in the details of the interoperability layer that OAuth and OpenID provide.

Prioritizing Security and Data Control

The solution has found adoption in multiple industries, with particular use in the banking industry. “In the financial sector, Authlete gives enterprises the ability to hold all of the sensitive information close to themselves,” explained Richer. “We don’t store user accounts. We don’t store names and passwords and addresses and account numbers and all of that other stuff. Instead, they tell us, I need an access token for the following subject identifier with the following rights and we deliver it.” Privacy-driven regulations and demand for privacy protections from consumers is changing how companies architect and deploy their systems, especially with regard to hosted services. Letting go of personal data to a cloud service is not a choice to be taken lightly, especially in highly regulated verticals. Authlete’s semi-hosted service architecture allows its customers to retain control over sensitive financial data and provide service that is hosted and controlled by the customer’s systems, while at the same time providing a state-of-the-art implementation of security protocols to protect these systems.

Security is an important but difficult aspect of modern systems, and deploying security protocols like OAuth and OIDC brings its own benefits and challenges. At the end of the day, developers want to provide the best functionality for their users, and Authlete provides a compelling and unique approach to securing that functionality.

Check out to try out Authlete for an extended 90-day free trial. 

Full Disclosure: Authlete is a sponsor of Software Engineering Daily



Software Daily

Software Daily

Subscribe to Software Daily, a curated newsletter featuring the best and newest from the software engineering community.