In this inverted flow ( from what has been proposed in the draft) Ideally the RO should not need to register a client, given that it does not need to make any calls to any endpoints. This will leave TP as the only party that should require to register a client. The reference to RAR is related to the need to identify the policy at AS that will govern the authorization. Just given the scopes might not be enough. Also there could be additional details in the authorization request to facilitate fine(r) grain authorization. Anyway, it is not super critical, however, I feel that at least resource indicator should be added to the client_credentials request to indicate to the RO (via AS) which resource(s) TP wants to access. Regarding authenticating AS requests to RO endpoints, signing of the request may be needed for RO to authenticate the request but it might not be enough… The other thing that bothers me about this flow is that it is using token endpoint for authorization request which does not sound right… Also it requires chaining of synchronous calls from TP to AS to RO which may be problematic, although in machine to machine calls may be OK, however, if I am implementing the AS I will not be super thrilled …
I will be traveling for the next couple of weeks, so I may not be able to respond in a timely manner, but lets continue this discussion… Regards, Igor Sent from my iPhone On 21 May 2024, at 02:00, Warren Parad <wpa...@rhosys.ch> wrote: One way to solve for which RO should AS engage to approve the TP request could be to incorporate a new metadata element in the TP client registration to specify the RO endpoint, or something like that. Maybe RAR extension can also be used with the client_credential grant type to add more details on the actual delegation required and then those details can be passed on to the RO for approval. The authentication between the AS and the RO for approval requests will also need some consideration… The only potential drawback is that RO needs to implement the approval endpoint, and in my experience that could be a problem… it is much easier for ROs to make calls to other people’s endpoints ☺ The TP calls the AS, which then in turns needs to call the RO. Therefore I believe the additional metadata element would need to be in the RO's client registration, not the RS or the TP. I think there was a misunderstanding with the Human user in the loop, that was as an example, I didn't mean to suggest that having a human solves the problem, but rather could need to be utilized and supported depending on the flow we pick. Also I'm not sure I understand the suggestion to the last point accurately, besides the RO metadata endpoint, there wouldn't need to be a RAR extension or extension on the client_credentials because the TP can already request scopes in the initial request to the AS. Would that not be sufficient? Re: The authentication between the AS and the RO for approval requests will also need some consideration So true, although we have a pattern for authorization codes, e.g. we use those to secure communication between two entities on the other side of the flow, I could see that being somewhat sufficient here, but it would require additional thought. Although we're already defining the concept of the callback for the UI applications, I would imagine that the same parameter would be used to configure the target for async requests by the AS. Re: The only potential drawback is that RO needs to implement the approval endpoint, and in my experience that could be a problem… it is much easier for ROs to make calls to other people’s endpoints Eh, I'd like to see that actually being a problem before attempting to switch up the flow. If anything, getting every oauth library out there to start including yet another endpoint is frequently a larger lift. Since we can expect that only a small percentage of implementations need this support it would be much better to push that need to that edge case rather than force every integration out there to support it just in case. Since the AS needs to support this anyway, having the AS call the RO seems like the first step no matter what. If in the future we need to reverse the support or codify policy management at the AS, then that could be the third(?) step here. Arguably the bigger concern would be how to convey in the RFC the semantics of the expectations the AS should have when they call the RO. I.e. how long do they wait, is it async or sync, how do retries work, etc... Besides the advantages of Separation of Concerns and alignment with the current OAuth flow, An additional real advantage here is that the flow starts with the entity that desires the access. Whereas in the current Draft the flow starts with the TP but it isn't included in the authorization_code, somehow the RO would need to know to do this thing, AND it would need to know where and when to pass the code to the TP. Avoiding this communication solves this problem. When I think about this implementation it actually aligns a little bit with something we have been thinking about, but haven't taken it further than that. I would very much like to be involved in defining a Draft for that. On Mon, May 20, 2024 at 12:55 PM Igor Janicijevic <i...@ivagor.com<mailto:i...@ivagor.com>> wrote: Hi Warren, Just for reference, the #3 question was: How does the RO decide which scopes to delegate to the TP client? Let me try to answer that through an example. RO client represents an organization that is a business customer of another organization that acts as a resource server (RS). RO wants to incorporate some special processing of its data held at RS into the services to its own customers. Rather than implementing that special processing itself, RO partners with a third party organization (TP Client) which specializes in that processing. In order to perform the required processing the TP needs access to the RO’s data held at RS. The RO has a full access to its own data held at RS and for that purpose it has a client registered with the AS including a number or resources (APIs) and a number of scopes. The RO knows what types of resources and associated scopes will be required for TP to perform that special processing, and typically this is a small subset of what RO as a resource owner can access at RS. The use case starts with the RO customer requesting a service from the RO. Instead of getting all the data itself from the RS, the RO sends the authorization request to the AS requesting a delegated access for the TP, asking for only the minimum required access in terms of resources and scopes. The AS responds with the authorization grant (authorization code). The RO then makes a service request to TP and passes the authorization code along. The TP exchanges the authorization code for an access token and then uses that token to access all the required data from the RS, performs the required processing and return the result to the RO. RO then uses that result to provide service response to its own customer. Although, it is possible to have the ongoing long lived delegation through refresh token issued to the TP, most of the time the delegation will be “once-off”, i.e. per service request with only short lived access token being issued to the TP. This can be controlled via scopes, for example if no “offline_access” scope is included in the authorization request, the TP will not be able to obtain refresh token from the AS. Depending on the nature of the request that RO’s customer is making to the RO, the RO may request delegation to different resources using different scopes – this will be a part of RO service configuration. RO can also engage multiple TPs doing different types of processing as part of a single service request from its customer by implementing an orchestration of calls to its partners (TPs). I hope the above answers your question. Now, going to the flow that you suggested below, that is definitely more in line with a “standard” OAuth flow where TP asks for authorization and then AS asks RO for authorization. You can obviously involve a human user in the authorization, as you already pointed out. In fact I have seen this implemented in the “wild” where a human user with a role of an administrator is involved in approving the authorization requests for B2B flows using standard authorization_code grant type. Once the application obtains the refresh token it proceeds to make B2B calls using refresh token to refresh its access tokens until refresh token expires. After that the authorization process starts again. The obvious advantage of this solution that it uses the standard OAuth flow, however, there are significant drawbacks. For example, B2B processing relying on human intervention are not ideal from the operational point of view. Also, the “admin” person will have to be a nominal “resource owner” for all resources that the TP application needs to access, which typically means that system level credentials (and access) are given to a human end user… The other option that you suggested, with an RO endpoint for authorization approval, is actually quite interesting. One way to solve for which RO should AS engage to approve the TP request could be to incorporate a new metadata element in the TP client registration to specify the RO endpoint, or something like that. Maybe RAR extension can also be used with the client_credential grant type to add more details on the actual delegation required and then those details can be passed on to the RO for approval. The authentication between the AS and the RO for approval requests will also need some consideration… The only potential drawback is that RO needs to implement the approval endpoint, and in my experience that could be a problem… it is much easier for ROs to make calls to other people’s endpoints ☺ Regards, Igor From: Warren Parad [mailto:wpa...@rhosys.ch<mailto:wpa...@rhosys.ch>] Sent: Sunday, 19 May 2024 11:41 PM To: Igor Janicijevic <i...@ivagor.com<mailto:i...@ivagor.com>> Cc: Aaron Parecki <aa...@parecki.com<mailto:aa...@parecki.com>>; <oauth@ietf.org<mailto:oauth@ietf.org>> <oauth@ietf.org<mailto:oauth@ietf.org>> Subject: Re: [OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B Authorization Thanks for 1 and 2, but 3 is still the question that I feel is unanswered. Can you walk through a concrete implementation use case that highlights how exactly the RO would delegate this access? It isn't clear for me how the RO would actually dynamically determine what to do here without: * There only ever being one answer * OR a human in a loop Since the policies are needed somewhere, I could say a more powerful extension to OAuth would be an interface that would let the RO configure the policies in the AS. And then the TP would request the client_credentials grant as it does today. Since in OAuth, control over this is facilitated by the AS, this would avoid the necessity of the RO being called on every TP client_credentials request, and also avoid an extra call which doesn't exist in the client_credentials grant today. That is something I would definitely support. It would have a secondary benefit to also help codify the interface for which human approved user agent scopes could be changed. Additionally, I find the directionality of the requests in the Draft to be contradictory to the expected flow. A more consistent approach would be for the TP to request client_credentials and have the AS call the RO to verify. This is exactly the same flow that happens with the authorization_code grant except that instead of the RO being a machine client, it is a human in an AS provided UI. Which means it would definitely make sense to flip this and instead define in the draft: * Endpoint configuration for the RO to accept AS driven client_credentials delegation requests * Request/Response configuration for that endpoint This is much cleaner: <image002.jpg> And we can see that because it is the exact same flow that OAuth does today, where the RO is a human's user agent in the browser, and (B) and (C) are actually the display of the /authorize endpoint and the "sign in" button that exists in the UI. This means that if the DRAFT would instead define exactly the nature of how the UI (or any user agent) communicates with the AS, this would be a huge win. On Sun, May 19, 2024 at 2:41 PM Igor Janicijevic <i...@ivagor.com<mailto:i...@ivagor.com>> wrote: Yes, it can be managed through some client specific policies at AS, however, as already stated in the 6749 the method of arranging this policy is not specified. The proposed draft describes how resource owner can dynamically manage delegation for third party client(s) so that no additional policies are needed at AS. From: Aaron Parecki [mailto:aa...@parecki.com<mailto:aa...@parecki.com>] Sent: Sunday, 19 May 2024 10:23 PM To: Igor Janicijevic <i...@ivagor.com<mailto:i...@ivagor.com>> Cc: Warren Parad <wpa...@rhosys.ch<mailto:wpa...@rhosys.ch>>; <oauth@ietf.org<mailto:oauth@ietf.org>> <oauth@ietf.org<mailto:oauth@ietf.org>> Subject: Re: [OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B Authorization Yeah this just sounds like the client credentials grant with some policy at the AS. There's no limitation that the client credentials grant is only used to access resources owned by the client. From 6749: The client can request an access token using only its client credentials (or other supported means of authentication) when the client is requesting access to the protected resources under its control, or those of another resource owner that have been previously arranged with the authorization server (the method of which is beyond the scope of this specification). On Sun, May 19, 2024 at 5:16 AM Igor Janicijevic <i...@ivagor.com<mailto:i...@ivagor.com>> wrote: The idea is that the resource owner client can delegate some or all of its own scopes. For example, if the resource owner client can obtain “read” and “write” scopes on its own resource, it can decide to delegate “read” scope for that resource to the third party client, but not the “write” scope. This means that the third party client will only be able to obtain read only access to that resource and will not be able to update the resource. From: Warren Parad [mailto:wpa...@rhosys.ch<mailto:wpa...@rhosys.ch>] Sent: Sunday, 19 May 2024 9:57 PM To: Igor Janicijevic <i...@ivagor.com<mailto:i...@ivagor.com>> Cc: Thomas Broyer <t.bro...@gmail.com<mailto:t.bro...@gmail.com>>; <oauth@ietf.org<mailto:oauth@ietf.org>> <oauth@ietf.org<mailto:oauth@ietf.org>> Subject: Re: [OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B Authorization Hmmm, interesting. How does the first-party client decide which scopes to grant to the third party service? On Sun, May 19, 2024 at 1:52 PM Igor Janicijevic <i...@ivagor.com<mailto:i...@ivagor.com>> wrote: Maybe I failed to set the context here, as you rightly pointed out. This new proposed flow is for B2B or system to system interactions only, i.e. no user agents (browsers) and no humans (end users) are involved, so there are no user agent redirects… In standard OAuth, for system to system access tokens are obtained using client_credentials grant type, where resource owner client authenticates to AS and obtains a token which it then uses to access its own resources held at resource server. No third party client is involved in this flow because this is direct access by resource owner to its own resources – there is no delegation and no “on behalf of access”… There is no delegated flow for system to system access in the standard OAuth, as far as I know… From: Warren Parad [mailto:wpa...@rhosys.ch<mailto:wpa...@rhosys.ch>] Sent: Sunday, 19 May 2024 9:18 PM To: Igor Janicijevic <i...@ivagor.com<mailto:i...@ivagor.com>> Cc: Thomas Broyer <t.bro...@gmail.com<mailto:t.bro...@gmail.com>>; <oauth@ietf.org<mailto:oauth@ietf.org>> <oauth@ietf.org<mailto:oauth@ietf.org>> Subject: Re: [OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B Authorization Maybe let's separate those two things for a second: 1. Third party acquiring token to access RS 2. RO revoking token generated for the Third Party client For #1. I'd be interested to know how this is any different from an OAuth Client that wants to access RS on behalf of the RO. In this case the "Client" would be the Third Party (TP). TP redirects user agent to AS to authorize token generation, then AS redirects user agent back to TP with auth_code/refresh token/etc. The token issued by AS to third party client is not presented to the resource owner client Correct, and isn't that the same as the standard OAuth flow? If not I think additional context there would be appreciated. - Warren On Sun, May 19, 2024 at 1:01 PM Igor Janicijevic <i...@ivagor.com<mailto:i...@ivagor.com>> wrote: Hi Warren, There are four parties in this flow: the resource owner client, the third party client, the resource server and the AS. The token issued by AS to third party client is not presented to the resource owner client – it is only presented to the resource server when third party client is accessing the resources. This means that the resource owner client cannot revoke that token because it will have to have a possession of it to present it to the revocation endpoint… Maybe I am completely missing your point, so can you, please, clarify. Cheers, Igor From: Warren Parad [mailto:wpa...@rhosys.ch<mailto:wpa...@rhosys.ch>] Sent: Sunday, 19 May 2024 7:14 PM To: Igor Janicijevic <i...@ivagor.com<mailto:i...@ivagor.com>> Cc: Thomas Broyer <t.bro...@gmail.com<mailto:t.bro...@gmail.com>>; <oauth@ietf.org<mailto:oauth@ietf.org>> <oauth@ietf.org<mailto:oauth@ietf.org>> Subject: Re: [OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B Authorization But the AS is already governing the access between clients, so at the surface at least I'm not able to wrap my head around your counterargument. Also this: Also, the resource owner client cannot easily revoke tokens issued to third party clients that it federates access with. Why not? It is just as easy to revoke a token issued to third party clients as it is to do in any OAuth compatible RS. What makes this case special for you, that the "Resource Owner" (your service client) in this case would not be able to revoke the tokens issued to the "Client" (the Third party application). Isn't this all doable with OAuth in spec without any magic? On Sun, May 19, 2024 at 10:28 AM Igor Janicijevic <i...@ivagor.com<mailto:i...@ivagor.com>> wrote: Yes, technically you can use token exchange to federate access but you have to manage AS policy for each combination of clients that need to exchange tokens. Also, the resource owner client cannot easily revoke tokens issued to third party clients that it federates access with. This draft tries to address those issues by giving resource owner client ability to delegate as much or as little access as they need to as well as the ability to revoke that delegation at any point in time. This also means that AS does not need to maintain policy that governs the federation (or delegation) of access between the clients. Regards, Igor From: Warren Parad [mailto:wpa...@rhosys.ch<mailto:wpa...@rhosys.ch>] Sent: Sunday, 19 May 2024 1:36 AM To: Thomas Broyer <t.bro...@gmail.com<mailto:t.bro...@gmail.com>> Cc: Igor Janicijevic <i...@ivagor.com<mailto:i...@ivagor.com>>; <oauth@ietf.org<mailto:oauth@ietf.org>> <oauth@ietf.org<mailto:oauth@ietf.org>> Subject: Re: [OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B Authorization That was my first thought, but since we only have one AS, isn't just this just OAuth but switching up which is the RS and which is the user agent? Why wouldn't the third party just request a client_credentials grant for the RS using the appropriate audience? On Sat, May 18, 2024, 16:52 Thomas Broyer <t.bro...@gmail.com<mailto:t.bro...@gmail.com>> wrote: Isn't that covered by Token Exchange already? https://datatracker.ietf.org/doc/html/rfc8693 Le sam. 18 mai 2024, 16:29, Igor Janicijevic <i...@ivagor.com<mailto:i...@ivagor.com>> a écrit : Dear All, I have published an Internet Draft document that I would like to introduce to the OAuth working group for consideration. Here is the link for your reference: https://www.ietf.org/archive/id/draft-janicijevic-oauth-b2b-authorization-00.html Abstract Delegated B2B Authorization enables a third-party OAuth client to obtain a limited access to an HTTP service on behalf of another OAuth client which is acting as a resource owner. This specification extends the OAuth 2.0 Authorization Framework with two new endpoints which allow a resource owner OAuth client to manage access for a third-party OAuth client. Motivation I work for a large financial services organization, and we are using OAuth 2.0 extensively to secure API based B2B integrations with various third parties by utilizing OAuth client_credentials grant type. Some of those third parties are our customers, while others are either our partners or partners of our customers. One of the challenges that we have encountered is that there is no standard way to delegate access to resources in B2B integrations, so that one party can obtain access to protected resources on behalf of another party. The above internet draft describes a possible extension to OAuth 2.0 that may be able to address this issue. I am looking forward to receiving your feedback. Regards, Igor _______________________________________________ OAuth mailing list -- oauth@ietf.org<mailto:oauth@ietf.org> To unsubscribe send an email to oauth-le...@ietf.org<mailto:oauth-le...@ietf.org> _______________________________________________ OAuth mailing list -- oauth@ietf.org<mailto:oauth@ietf.org> To unsubscribe send an email to oauth-le...@ietf.org<mailto:oauth-le...@ietf.org> _______________________________________________ OAuth mailing list -- oauth@ietf.org<mailto:oauth@ietf.org> To unsubscribe send an email to oauth-le...@ietf.org<mailto:oauth-le...@ietf.org>
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org