OAuth: Beyond the Standard
OAuth is a standard granting a server authorization to access protected data on another server. As there are a myriad of places on the internet to explain ‘how’ it works or ‘how’ to set it up, we will not discuss that in this post. Rather, we will highlight how it’s commonly used by our clients as part of efforts to modernize IAM solutions. OAuth is rarely the complete picture, as clients need more than a standard ‘off the shelf’ implementation to meet business objectives.
Below, we’ll highlight three ways we’ve taken standard OAuth functionality and added value by combining it with other technology.
Client Credentials
Flow
A client credentials grant flow is a basic OAuth use case. In the typical client credentials case, the authorization server is allowing the client to access the resource server without any end user interaction. As such, there is no consent flow.
The client begins by requesting an access token from the authorization server using the client id (a publicly exposed string used by the service API to identify the application) and secret (the key stored on server side securely and should not be publicly available). Once granted, the client presents the access token to the resource server as part of a resource request. The resource service validates it against the authorization server, ensuring it has the scope necessary for the request. If valid, the resource server responds to the request.
Customizations
An organization wanted to use this design to authorize applications to access APIs; however, they didn’t want to place the burden of access token validation onto each application. To facilitate, we added an XML gateway to handle the resource-to-scope mapping and token validation.
Unfortunately, this wasn’t enough to meet requirements. Management of the client id, secret and scopes (a mechanism to limit an application's access to a user's account) was still done within the access manager (AM) platform and would have required a separate team from the organization to be involved in each deployment.
To remove this hurdle, a custom client plugin allowed AM to interface with an existing Lightweight Directory Access Protocol (LDAP), effectively delegating authentication and authorization administration. With this in place, AM was now part of the organization’s existing process for creating and authorizing service accounts. This removed duplicate work during deployments and provided a scalable framework for centralized service account management to APIs!
Resource Owner
Flow
In the resource owner grant flow, the client does not use its individual id and secret to connect. Instead, it uses the end user’s credentials. This flow continues like the client credentials flow (shown above) after this point. When the client receives an access token for the resource server, the access token is tied to the authenticating user (rather than the client application shown in the previous example). Typically, we do not recommend using the resource owner grant flow as it provides a user’s username and password to a client directly, which creates numerous security concerns.
Customizations
For an organization, we developed a front-end single-page application (SPA) that provides login and a self-service user interface for a cloud identity service. The cloud service rightfully required an access token for self-service operations, so we chose this rather than a public client with the implicit flow. The login application obtains the access token at the same time as the authentication event, so the SPA can securely act on behalf of the user - despite being a fully browser-based client!
Authorization Code
Flow
The authorization code grant flow is possibly the most well-known flow to end users. It builds upon client credentials grant flow by forcing the client application to gain authorization to access a user’s data. When a client application needs access to a user’s data in a resource server, it will redirect the user to the authorization server.
If the user is not already authenticated, the authorization server will prompt the user to login and, typically, give consent to the client’s request. Once authorized, the user is redirected back to a whitelisted endpoint for the client to receive the authorization code. The client application then uses this code to retrieve an access token from the authorization server, similar to how it has been used with the client id and secret. With this, it continues the OAuth transaction as before.
Customizations
An organization was looking for a combination of the implicit and authorization code grant flows. It was the user authentication (and the extra layer of OIDC) that added complexity and value to the solution. This organization needed different Levels of Assurance (the degree of confidence in the processes leading up to, and including, an authentication) based upon the access requested. This necessitated authentication using a mobile application on the user’s registered device, e.g., PIN, recovery code, biometrics, etc. The solution adds the specific authentication methods used (amr) to the id token, allowing the relying party to decide which methods were sufficient.
In each case, our solutions were implemented using the OAuth standard. While very important, it rarely meets all business or technology needs on its own. We utilized standard flows and built tailored customization around them, while keeping everything secure.
Taking a set of tools and a set of building blocks, combining them in just the right way to get exactly what we need, is what I love about these projects!
If you have any questions about how to optimize OAuth for your organization, contact us.