Robert Broeckelmann is a principal consultant at Levvel. He focuses on API management, integration, and identity–especially where these three intersect. He’s worked with clients across the financial, healthcare, and retail fields. Lately, he’s been working with Apigee Edge and WebSphere DataPower.
OAuth2 and OpenID Connect (OIDC) have their origins in the concept of delegated access—think three-legged OAuth. These protocols are designed around the notion that the resource owner is an end user; however, for the enterprise, the business may own the data and be responsible for determining when access should be granted. This post explores how an enterprise IT organization may go about defining policies around such access.
Delegated access is the act of one entity (a person or system) granting access to a resource that they own (or control), to another person or entity that has a need for access. The concept of delegation comes up over and over in identity and access management. The Kerberos protocol that Microsoft Windows security is built upon has delegation as a core concept.
Within three-legged OAuth (and OIDC) use cases, the credential validation mechanism is not specifically defined (not to be confused with the OIDC ID token, which conveys details of the authentication to the application). Yet it is generally assumed to include a consent-granting phase wherein the end user (who is being authenticated and owns a resource the third-party application wants to access) specifically grants permission or consents to the third-party application to access some resource. For our purposes, let’s assume this resource is an API that provides data the end user owns.
The evolving standard for API security
Ironically, these protocols that were designed for a very specific use case (three-legged OAuth and delegated access) grew into the defacto standard for authentication and authorization of API access, mobile applications, single page applications (SPAs), and others. To that end, OAuth2 (together with additions like JWT for the access token and additional security mechanisms to provide a minimal authentication protocol, which many of the enterprise IdP vendors would already do) and OIDC should be the starting point for any identity conversation in those spaces. There was a point, three years ago, where I would have said that OAuth2 should only be used in situations where delegated access is needed.
But the world of modern identity needs a standards-based approach to identity just as much as last decade’s SOA and SOAP web services did. There were not any other standards that had the industry’s major players backing it (and using it) that provided the requisite functionality. So that’s why I call OAuth2 the de facto standard of API and mobile security. Of course, that is evolving into OIDC being the de-facto standard.
So, we have OAuth2 and OIDC being used for a variety of use cases across SPA, mobile, API access, and traditional web application use cases that they were not necessarily originally specifically targeting. This bothered me in the beginning; I still interact with people today who do not really like this approach. But the ship has sailed already, so let’s make the best of it.
When the business owns the accessed resource
We live in a world where OAuth2 and OIDC are the standard for API security (at least where end-user authentication and identity propagation are concerned). These protocols assume a consent-granting step during the login workflow and assume that the user being authenticated owns the resource being accessed. What happens when the business owns the resource being accessed, instead of the user?
In the enterprise, this is a common scenario; especially in the business-to-employee (B2E) space. It’s possible in the B2B space, and in the B2C space it would depend on the jurisdiction and the exact circumstances. For the discussion here, let’s stick with the B2E space.
If the enterprise owns the data, then it owns the authorization decision regarding who and what can access that data. These decisions will be driven by the data classification assigned to the data in question. A typical data classification policy in a Fortune 100 company would be created by information security, legal, and representatives from the business side. The categories of data sensitivity could look something like this:
- Public classification Information that is meant for distribution to the public, including store location information, hours, anything on the public corporate web site
- Internal business use Information that is used in regular business processes; it generally isn’t meant for public disclosure, but if it were to be disclosed, it would not seriously harm the business, business partners, or customers
- Confidential sensitive information that should not be disclosed; If it is disclosed, destroyed, tampered with, or manipulated, it could cause significant damage to the business, business partners, or customers
An effective data classification policy will ensure that sensitive data is handled appropriately, based on the level of risk associated with it. This drives a data-loss prevention program, which forms one of the pillars of an enterprise authorization policy definition process. That and an understanding of the expected audience will drive the security semantics of the authorization policy of an API that is exposed to internal or external actors. The same is true for any IT system or app that provides access to data (most of them do), but we are interested in APIs. So, let’s focus on APIs.
In the enterprise, with the possible exception of personally identifiable information (PII), the data most employees, contractors, and business partners interact with is owned by the business, not individuals. Depending on what country you are in, the data may be written into contracts that the business has the right to access. It’s also possible that additional steps must be taken to have this level of access if data residency requirements are in play, but this is beyond the scope of this discussion.
The data classification policy drives the semantics of an API authorization policy. Before the semantics can be codified into a policy (whatever technical implementation that takes), the syntax of that policy must be defined. To that end, something like eXtensible Access Control Markup Language (XACML) could be used to author the authorization policy. The implementation of such policies is, again, beyond the scope of this post.
So if the data is owned by the business and not the individual, it follows that the business will be responsible for determining who (and what) is allowed to access and manipulate that data. The mechanisms used to accomplish this by the IT department have also been discussed (data classification policies and API authorization policies).
We have arrived at a place where we are using a delegated access (authorization) protocol (OAuth2 and OIDC) in a general case where the end users being authenticated don't own the data they are trying to access. As I mentioned before, we’re going to continue to use OAuth2/OIDC because that’s the best standard that has emerged in the API and mobile spaces.
To this end, the consent granting phase of the login workflow on the identity provider (the OpenID provider or authorization server) may be unnecessary. Most enterprise-grade identity providers will have features to support this. For example, Azure Active Directory provides a concept called administrator consent that allows permission to be granted on resources for all users in a tenant.
At least two different forms of authorization have been mentioned in this discussion: authorization decisions made during token issuance (authentication time) and authorization decisions made at runtime during resource access (API invocation).
By their very nature, the initial decision, made on the identity provider at the time of authentication and token issuance, is more coarse-grained than the decision that can be made at the time of API invocation on the API provider (or possibly the API gateway). This is because there is far more information available at runtime during the API invocation then there is during the token issuance about the context surrounding exactly what the end user or application is attempting to do.
As an example, in one large client, the decision was made to use the information that was available at the time of token issuance to scope the token (the JSON web token, or JWT) to a known API audience that would be accessed. This audience information combined with strict audience enforcement information at the API provider (or API gateway) ensured that tokens were not reused between environments (unit test, QA test, load test, and production, for example).
Taken one step further, the audience information can be scoped to a particular API or set of API functions. It can even implement a basic RBAC (role-based access control) model to protect the API. Yet a mechanism still has to exist on the API endpoint to correctly map the audience (role) to the resource—this is common functionality in an API gateway. Many other authorization schemes are possible.
How closely the consent and delegation can be integrated between the IdP and the API provider depends upon the system and its features. But, for most of my enterprise clients, in the B2E space the consent step for the end user isn’t present and, instead, there is an evolved authorization policy concept defined at the API provider layer.
In order for this to happen, enough information has to be present to make authorization decisions in the token (the JWT-based access token or the ID token), including LDAP attributes, group information, role information, context-specific information about the environment or application, and what is defined by the JWT, OIDC, and JWS specs.
The OAuth2 and OIDC specs are employed in use cases now that they weren’t originally meant for, but the industry needed a standards-based, interoperable approach to application security. This is why they’ve become the defacto standard for API authentication and authorization. Moving forward, these specifications (especially OIDC) will be the standard that enterprise identity is built upon.
Read other posts that Robert has contributed to the Apigee blog.
Image: The Noun Project / Arthur Shlain