Hi all, I’d like to pitch the idea of changing the abstract OAuth description to incorporate how OAuth is used in many B2E applications. In my view, OAuth 2.1 is a great opportunity to do so, without the need to make any changes in the core protocol itself, so nothing gets ‘broken’. The 2.1 RFC would be just acknowledging how OAuth is already used widely today.
To the best of my understanding, OAuth (as per RFC6749) originated from a Business-to-Consumer (B2C) context. The typical example that is frequently used to explain OAuth is about an enduser (resource owner) that can grant a printing service (client) access to their protected photos stored at a photo sharing service (resource server). What I see in everyday practice in the IAM field, is that OAuth is used for Business-to-employee (B2E) applications (often in combination with the OIDC extension). In this context, the enduser is not the resource owner. Instead, the company is owning the resources stored at its resource servers and employees (or other type of endusers) are granted access based on roles/rules implemented at the resource server. One may say that OAuth was not designed for such B2E scenarios, but I would say that the protocol is perfectly suitable. Practice proves this. I don’t have hard data to further prove my point but I expect OAuth is worldwide being used more often for B2E like applications than it is for B2C applications. The good news is that the narrative around the core specs can be re-written to make it more generally applicable without changing the protocol itself. I think this will be beneficial to anyone working with OAuth, newbies or experienced IAM workforce. In my view things will be easier to understand and closer to daily practice. The main changes I’m proposing for section 1 are the following. Changes in the rest of the draft RFC follow naturally. 1. In the introduction I would add: “A different example is: an employee (enduser) can use an application (client) to access resources that are under control of his employer (resource owner).” 2. I would also add: “Besides delegating user authentication to the authorization server, the authorization server can arrange for an authorization decision through a process that involves neither client application nor service. If the enduser is the resource owner, the authorization server obtains an authorization grant from the enduser. If a different entity is the resource owner, the authorization server may make an authorization decision based on prearranged rules or roles.” 3. In section 1.1, I would propose to define 5 roles instead of 4. OAuth defines five roles: “enduser”: Person that uses a client application to access protected resources on their behalf. "resource owner": An entity capable of granting access to a protected resource. The resource owner may be the enduser or it may be a different person or it may be an organization. This is sometimes abbreviated as "RO". "resource server": The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens. The resource server is often accessible via an API. This is sometimes abbreviated as "RS". "client": An application making protected resource requests on behalf of the enduser and with the resource owner’s authorization. The term "client" does not imply any particular implementation characteristics (e.g., whether the application executes on a server, a desktop, or other devices). "authorization server": The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization from the resource owner or making an authorization decision on behalf of the RO. This is sometimes abbreviated as "AS". 1. Mostly the term resource owner needs to be replaced with “enduser” except when it is about authorization. 2. In section 1.2, I propose to revise the abstract protocol flow description to say that it’s the authorization server that somehow obtains/makes an authorization decision. In the current abstract description of the OAuth flow it is the client that obtains the authorization. However in the actual grant flows there is never such interaction between client and resource owner. Neither in the Authorization Code flow nor the Client Credential flow. In fact it’s always the AS that somehow arranges for an authorization decision: in AC flow, the AS may get consent from the enduser/RO and in the CC flow it is based on a previous arrangement. I think the following alternate abstraction would have a better fit with the various grant flows: “1. The client requests authorization from the authorization server. 2. The authorization server obtains an authorization decision from the resource owner. This decision can be obtained by interaction with the resource owner or can be made made using logic that was pre-arrenged with the resource owner. 3. The client receives […etc…]” Furthermore, I think that my proposal opens up OAuth for more scenarios, such as one consumer may granting another consumer access to its resources (UMA-like) and the AS would have a match with the concept of a Policy Decision Point (as per XACML specs). I’m very curious to see your feedback on my proposal. Do you agree with my point of generalizing beyond B2C? Do you agree that Oauth 2.1 is the right opportunity to generalize OAuth from B2C to a wider set of scenarios? Kind regards, Jaap Francke Product Manager IAM +31(0)641495324 mendix.com [signature_827714327]<http://www.mendix.com/>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
