Re: [OAUTH-WG] OAuth 2.1 & B2E apps (Jaap Francke)

[Jaap Francke <[e-mail]>]

Hi all,

Early March I shared the suggestion to make the abstract OAuth protocol description a bit more generic so it would not only have a fit with B2C use cases but would suit B2E use cases as well.
I haven’t seen any response from you – I find myself wondering why.
As my suggestion still makes sense to me, I’d appreciate a response.
Thanks in advance!

Cheers, Jaap

From: OAuth <[e-mail]> on behalf of [e-mail] <[e-mail]>
Date: Thursday, 2 March 2023 at 20:00
To: [e-mail] <[e-mail]>
Subject: OAuth Digest, Vol 173, Issue 7
Send OAuth mailing list submissions to
        [e-mail]

To subscribe or unsubscribe via the World Wide Web, visit
        https://www.ietf.org/mailman/listinfo/oauth
or, via email, send a message with subject or body 'help' to
        [e-mail]

You can reach the person managing the list at
        [e-mail]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."


Today's Topics:

   1. Artart last call review of
      draft-ietf-oauth-step-up-authn-challenge-12
      (Robert Sparks via Datatracker)
   2. OAuth 2.1 & B2E apps (Jaap Francke)


----------------------------------------------------------------------

Message: 1
Date: Thu, 02 Mar 2023 10:41:34 -0800
From: Robert Sparks via Datatracker <[e-mail]>
To: <[e-mail]>
Cc: [e-mail],
        [e-mail],  [e-mail]
Subject: [OAUTH-WG] Artart last call review of
        draft-ietf-oauth-step-up-authn-challenge-12
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="utf-8"

Reviewer: Robert Sparks
Review result: Ready with Issues

Summary: essentially ready but with issues to consider before being published
as a proposed standard RFC.

Issues:

I expected to find some discussion of considerations of avoiding "step down"
given the intuitive appeal to "step up". Can the client or Authorization server
notice if the resource server has through whatever fault asserted that it will
only accept the use of an authentication context class that is blatantly
inferior to what has already been provided? And if they notice, what is
expected to happen? Or is it expected that this is allowed, particularly when a
short max_age is also supplied?

The document also suggests that the client hold on to, and possibly re-use in
the future, access tokens that have been challenged as having insufficient user
authorization. Is this behavior something that follows a well-known and
well-implemented pattern documented elsewhere? If so, a pointer would be
useful. If not, this seems like something that deserves more discussion if not
more definition.

Nits:
The reference to abr-twitter-reply will go away with the changelog when the RFC
Editor removes it. It would be kind to acknowledge that in the note to the RFC
Editor so that they know it's expected and don't have to ask.





------------------------------

Message: 2
Date: Thu, 2 Mar 2023 18:59:26 +0000
From: Jaap Francke <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: [OAUTH-WG] OAuth 2.1 & B2E apps
Message-ID:
        <[e-mail]>

Content-Type: text/plain; charset="windows-1252"

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
[phone]
mendix.com
[signature_827714327]<http://www.mendix.com/>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/20230302/6a18cfb7/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 9766 bytes
Desc: image001.png
URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/20230302/6a18cfb7/attachment.png>

------------------------------

Subject: Digest Footer

_______________________________________________
OAuth mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/oauth


------------------------------

End of OAuth Digest, Vol 173, Issue 7
*************************************