My
previous post asked the question "Does OAuth do authentication"? In this post, I explore
OAuth2 and its support of authorization.
When most people ask the question about whether OAuth2 supports authorization, you might be thinking in terms of today's authorization/access management/policy systems. But, as mentioned in my previous post, authorization here is within the terms of how HTTP defines it. A fairly low-level distinction that convolves authentication and authorization. To really answer the question we must look at how HTTP defines authorization. Then we can begin to look at the larger implications of how OAuth2 impacts authorization in a more modern, higher level view.
What is HTTP Authorization?
Consider authorization from the standpoint of HTTP/1.1 (
RFC2616). Section 14.8
defines authorization as a user-agent
providing an authorization request-header field with its HTTP request(often after receiving a 401 response). The value of the
authorization field consists of
"credentials containing the authentication information of the user agent for the realm of the realm of the resource being requested."
It seems that the authorization header specified in RFC2616 is not really an authorization, but rather an authentication credential. But consider the time frame when RFC2616 was authored. In that timeframe, authorization was rather simplistic. Do you have an account? If so, you are 'authorized'. Note: I may be over-simplifying the specifications here, but I think it you'll see more clearly where this is going.
So what does OAuth2 do for authorization?
Classic web access management (e.g.
Oracle Access Manager) support users who use browsers accessing protected web sites. Over time, the control exerted over what users could do has become increasingly fine-grained such is the vision with
XACML. Yet, typically these systems involve end-users requesting web resources rendered in browsers,
or distinctly there may be separate "service" managers (such as
Oracle Web Services Manager) supporting WS-* based services over SOAP.
OAuth2 supports a range of new use case scenarios. Many do not directly involve a user or a browser, but rather define a client application acting on behalf of a resource owner's (e.g. the user) behalf using only HTTP to access REST based services in a
lightweight fashion. From an authorization perspective, OAuth2 use cases introduce the new capability that client applications, each with their own identity, act on behalf of a users that own resources and can perform service calls with a specified "scope". In its simplest form, OAuth2 provides a means to identify and perform authorization of two security credentials: that of the user that owns a resource, and that of an application.
What credential relationships are supported?
OAuth2 enables most combinations of relationships and in theory allows for extensions define new ones. Currently defined are:
- A client app, who also has the resource owner credentials, acting on behalf of a resource owner (see Resource Owner Password flow).
- A client app obtaining user/owner authorization (see Authorization Code flow).
- An unidentified client (typically javascript in a browser) acting on behalf of a resource owner (see Implicit Grant flow).
- A client app acting using its own authority (see Client Credential flow).
- A relationship defined using an extension (see Extensions flow). For example, a client app using an externally generated SAML2 Bearer assertion. The SAML assertion defining what Identity and/or what rights are being expressed.
What about OAuth2 authorization goes beyond security credentials?
RFC 2616 together with sister specification
RFC2617 (Basic Authentication) define a rather simple notion of "authorization" as simple rights corresponding to a single user account. In OAuth2, we have the possibility of 2 entities: a client app acting on behalf of a resource owner.
But, to further narrow the focus from specifically what a specific client can do can do in a particular credential relationship, OAuth2 introduces the notion of scope. Scope defines capabilities of a client application performed on behalf of the resource owner. These capabilities may be thought of as roles or entitlements within the resource API. Typical examples are of the style: readProfile, updateProfile, readStatus, updateStatus, readBalances, payBills, executeTrades and so on. OAuth2 says almost nothing about what the possible values of scope can be - it is entirely up to the site being protected to determine meaning. In theory then, it is possible to set very specific scope such as the right to access a very specific URL. But in practice, it seems the use of scope is usually defined by the underlying web service API as enabling simple "capabilities".
What forms of authorization can be supported by OAuth2?
OAuth2 systems can support any number of authorization systems so the types of authorization that can be supported are unlimited. However, because the end-result of an OAuth2 authorization flow is always an authorization token (aka access token) to be used in a subsequent operation, the types of authorizations that can be handled are limited to those decisions that can be calculated in advance. At the time of authorization in OAuth, remember that that actual resource has yet to be accessed, so no transaction is occurring.
As an example, consider that OAuth2 systems can clearly handle [actors and scopable actions bolded for emphasis]:
"CheckPayer may writeChecks for Phil"
vs. a contextual or transactional authorization decision of
"CheckPayer may write a check on behalf of Phil for $50 payable to Nishant now".
The latter decision will still have to be decided by a policy system within the context of the transaction rather then within the context of an OAuth2 authorization. The reality is the likely OAuth2 products will define a mix of "capability" style authorizations together with access management systems. Thus if, the first statement was known as "philCheckToken" embodies the right of a client to write checks for "Phil", then the transactional statement might be:
"philCheckToken writes check for $50 payable to Nishant"
We know that the client (identified by philCheckToken) is allowed to writeChecks for Phil. Now the transaction policy simply checks to see if Nishant is a valid recipient and if the amount is within policy (and potentially whether Phil has $50). In OAuth2, these authorization systems will work together to make in-advance "capability" assertions, together with applying fine-grained decisions in the context of actual transactions.
