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
