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> 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] > *Sent:* Sunday, 19 May 2024 9:57 PM > *To:* Igor Janicijevic <i...@ivagor.com> > *Cc:* Thomas Broyer <t.bro...@gmail.com>; <oauth@ietf.org> <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> 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] > *Sent:* Sunday, 19 May 2024 9:18 PM > *To:* Igor Janicijevic <i...@ivagor.com> > *Cc:* Thomas Broyer <t.bro...@gmail.com>; <oauth@ietf.org> <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> 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] > *Sent:* Sunday, 19 May 2024 7:14 PM > *To:* Igor Janicijevic <i...@ivagor.com> > *Cc:* Thomas Broyer <t.bro...@gmail.com>; <oauth@ietf.org> <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> 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] > *Sent:* Sunday, 19 May 2024 1:36 AM > *To:* Thomas Broyer <t.bro...@gmail.com> > *Cc:* Igor Janicijevic <i...@ivagor.com>; <oauth@ietf.org> <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> 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> 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 > To unsubscribe send an email to oauth-le...@ietf.org > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
