Author: Vadim Lander, Chief Identity Architect, Oracle
The OAuth standard has proven itself to be a very effective in managing distributed Web authorization by providing client applications a secure, delegated access to server resources on behalf of a Resource Owner. A large number of public Internet web sites have standardized on OAuth for service-to-service authorization, the standard has gained traction in securing commercial SaaS/PaaS/IaaS services cloud, and is being adopted by enterprises interested in externalizing internal web services.
Here at Oracle we're using OAuth2 to secure access to Web Services exposed by Oracle Public Cloud services. While the standard itself is relatively straightforward, there are a couple of areas that each implementation must address on its own. The purpose of this blog is to look at one such area we have to advise application developers on - how to deal with OAuth scopes. We will assume the reader is familiar with the standard OAuth terminology.
Figuring out what scopes to expose is a responsibility of an application developer, and it may be confusing at first:
- Do I expose a single scope protecting the entire service, or do I expose scopes to protect fine-grained business functionality of my application?
- Do I break up my service into many smaller services with one scope each, or do I build multi-functional service with multiple fine-grained scopes?
- How do I balance the needs of my clients to request specific capabilities and the needs of my application owners to manage appropriate policies?
Lets take a closer look at scopes, and see what it means to request scopes that will be granted by the Authorization Server and placed into the Access Token.
An OAuth scope X is an indication by a client that it wants to access the Resource Server to perform X or access something on the service that is related to X. For example, the client may request a claim EMAIL_SERVICE to access the email service, or it may request claim DELETE_INBOX if it desires to delete inbox entries.
The developer of the email service needs to think about what scopes should be exposed in a way that lets services support different types of clients by allowing proper authorization delegation. In the previous example, the “EMAIL_SERVICE” scope is generic and might not be that useful because it grants too much authority. If the email service breaks this into scopes such as “EMAIL_READ”, “EMAIL_POST”, “EMAIL_MOVE”, and “EMAIL_DELETE”, the core functionality of the email service is expressed as scopes. This becomes useful to allow clients to use minimal authority to access the user’s mailbox without requiring full access.
As mentioned previously the purpose of OAuth is to authorize access to a service. Hence some Policy Enforcement Point (PEP) will be tasked with securing access to the Resource Server must be able to determine from the Access Token's authorized scopes whether or not access should be allowed. Once the token is issued to a client, client's access rights will be bound by scopes encapsulated by the Access Token for as long as the Access Token is valid.
The big question is where to draw the line between defining very granular scopes representing the right to invoke functional "capabilities" exposed by physical service implementations, and creating broad scopes representing the right to invoke the actual physical services.
One important perspective on how to answer this question is to look at the problem from the perspective of the Resource Owner - specifically what authorization decisions need to be made to authorize requested scopes, how often these decisions needs to be made, and what needs to be known in order to make such decisions. The lifecycle of managing such authorization decisions should be straightforward – otherwise the policies will be incomplete, out of date, or overly permissive.
From the Resource Owner perspective there are two important considerations:
- Who owns the data - end user or the target service
- Who gets to specify the authorization policy - end user or application owner
The difference in considerations is important since it determines who gets to authorize the client's request for specific scopes - end user who's data will be requested by the client, or the business/security admin configuring the client and granting it specific privileges. Lets take a close look at each consideration:
End users authorizing request for scopes
If the Resource Server is tasked with providing access to end user's data (such as the case with consumer sites or user-centric apps such as email), the end user is the ultimate authorization authority for deciding whether or not requested scopes should be granted.
In this case the purpose of a scope is to let the end user know what the client is trying to do with end user's data (ex: Requesting access to one's pictures or emails, requesting access to one's mobile GPS data, etc.). Then when the Access Token is granted, the approved scopes are "burned" into the token. Presenting this Access Token to the Resource Server conveys the fact the end user has approved client application's request to access his/her data.
We can see that scopes represent client's intent to access user's data, and can be modeled based on the number of user's data categories the Resource Server wants to protect from "super user" access.
This requirement to secure access to end-user's data is the primary reason for the 3-legged OAuth interaction where the end user (data owner) is responsible for providing consent to operations requested by the client. Here, the end user is familiar with, and wants to protect access to his/her data, so modeling scopes based on user's data categories (or collection of categories) makes sense. This model is often used by user-centric cloud services such as mail, photos, storage, documents, etc.
Business admins authorizing request for scopes:
There are numerous commercial/enterprise services where the Resource Server is consumed not by the end user directly, but by partners who build clients to consume, expose, or extend application functionality.
In this case the purpose of scopes is to represent authorization permissions as granted by an administrative process responsible for registering clients. For example, a real estate site is exposing listings, where unpaid clients have access to listings without addresses, while paid clients have access to addresses. Here, “Address” would be a scope, and it would be the service administrator configuring clients and granting them allowed scopes based on the level of service a client has paid for.
We can see that scopes represent fine-grained capabilities the Resource Server is charging for, using administrators (or automated sign up processes) to decide the authorization policy.
Looking at both scenarios, we can conclude that having too many scopes will create a burden on some user to try and understand/manage the meaning of scopes.
In the case of user-centric scopes, the end user is expected to understand the meaning of the data managed on his behalf.
In the case of business admins, they're expected to understand business rules (or in the case of automated client registration, have the ability to collect required service-level agreements).
The more scopes are exposed by a Resource Server, the greater the burden on a user (end user or administrator) to understand the exact meaning.
Hence, the overarching goal of application developers is to make their users capable of understanding the underlying authorization process, and this requires looking at scopes not only from the application development perspective but also from "administrative" knowledge and life cycle burden a developer might inadvertently create - some human being will have to be responsible for and trained in understanding the meaning of scopes.
Ultimately, the application developer has to think about what scope means in the context of “their” application, including how much delegation (to an end user or policy) should be exposed. There will be as many scopes as the developer wants to expose to a user who is expected to understand their meaning – this could be an end user of social/mobile app clients accessing his/her data, or a security policy admin for enterprise/commercial applications.
Overloading with too many fine-grained scopes will place a burden on the user, creating confusion or complicating policy administration. Its best to define few scopes protecting the high level service, adding few additional scopes to secure access based on read/write operations, and only then take a closer look at whether or not any additional scopes are required.
This is it for the first installment on OAuth scopes. In the next blog, we will look at other scope-related topics:
- Scope affinity. Can a client with a given scope access any resource or only the resource associated with the authorizing (and/or owning) user?
- Scope changes. The Authorization Server is free to grant a different set of scopes than what a client requests. This can happen because of policy, user consent, or just versioning issues.
- Scope risk. The Authorization Server might issue different tokens with different lifespans based on the scope requested.
- Implicit scopes. Some scopes may be “implicit” where the policy dictates whether user, or a client on user’s behalf is authorized to do something – resulting in “automatic” consent with no actual consent dialog.
- Privileged scopes. The Authorization Server may inject special scopes not requested by clients, by granted non-the less based on the contextual state of the client.
For more information on OAuth please see http://oauth.net/2/
About the Author
||Vadim Lander joined Oracle’s Identity & Access Management team in 2009. He advises Oracle on key security technology trends, sets the technical strategy for the IAM Enterprise and Cloud product lines, and works with various Oracle teams on the architecture and implementation of the IAM stack.
Previously, Vadim was CTO for the Security BU at CA delivering the architectural blueprints for engineering CA’s next-generation solutions. Vadim joined CA in 2004 with its acquisition of Netegrity, where he was CTO after holding a number of successive growth positions in engineering.Vadim holds a Bachelor of Science degree in Computer Science from Northeastern University in Boston.
|Vadim can be reached via LinkedIn
Visit the Oracle Technology Network for more information about Oracle Identity Management Products including downloads, documentation and samples
Engage with us on Twitter @oracleidm and
follow us here in the Identity Management blog.