The token exchange endpoint at ASf has no ability to issue a usable access token in this case. The client has to talk to the token exchange endpoint at ASr to get an access token to be used at the RS, IMHO.
2016年8月5日(金) 20:20 Sergey Beryozkin <[email protected]>: > Hi Nat > On 05/08/16 11:16, Nat Sakimura wrote: > > I can sort of understand why people would want to do it, and there are > > legitimate cases. > > > > This is the case where the RS is in fact an AS (ASr) in that resource > > domain and the RS is dependent on the federated AS (ASf) for the > > authentication. In such a case, the ASf cannot really make the access > > decision. > > It is the ASr that makes the decision based on the user authentication > > results, and possibly the authorisation result at ASf combined. To the > > ASf, the 'client' is the combination of the app that the user is using > > and the RS. So, the app sends the ID Token to the RS=ASr. This pattern > > is perfectly legitimate as long as the RS is also in the audience. > > > We've noticed that IdToken may have >1 audiences, in addition to the > client audience, but were not sure what extra audiences would be there, > so I can see now. > > In this case, when RS acts as ASr, and IdToken lists this RS in the > audience, is it still recommended for the client to exchange this > IdToken for a new token via a token exchange endpoint and forwarding a > new token to RS, or it it OK for the client to send the IdToken to RS > bypassing the exchange ? > > Thanks, Sergey > > > Best, > > > > Nat > > > > > > 2016年8月5日(金) 5:58 John Bradley <[email protected] > > <mailto:[email protected]>>: > > > > The token exchange spec allows for the token issued to have claims > > about the subject of the input token. This is what we generally > > think about as impersonation. > > That is really the same as a normal OAuth access token for the most > > part. > > > > You can also ask for a composite token that contains claims about > > the presenter and the original subject. This allows for the > > auditing of who is making the request for the subject. > > > > This sort of composite token was introduced in WS-Trust 1.4 and is > > called ActAs in that spec and we refer to as delegation. > > > > This is desired when a RS (A) receives a access token and then needs > > to become a client (A) to access another service in the context of > > the access token. > > > > The second RS (B) is protected and can’t be access directly by the > > the original OAuth client. The client (A) needs a new access token > > based on its client credential plus the original access token to get > > a token that RS (B) will accept. RS (B) also wants to know who > > the client that is accessing it for audit or other reasons. > > > > That is one of the things that the new delegated token type is for. > > The impersonation type is basically the same sort of impersonation > > type token that we use now. > > > > I admit that OAuth is vague about delegation vs impersonation and > > they are generally left as implementation decisions as the tokens > > are considered opaque. > > > > For token exchange we wanted to be more explicit so that the client > > has more control over the exchange. > > > > I hope that helps. > > > > John B. > > > > > On Aug 4, 2016, at 12:26 PM, Sergey Beryozkin > > <[email protected] <mailto:[email protected]>> wrote: > > > > > > Hi John > > > > > > I think it is closer to what I'm trying to understand :-). Let me > > work with the text below, I'll likely have few more questions to > > follow later on > > > > > > Thanks, Sergey > > > > > > On 04/08/16 17:04, John Bradley wrote: > > >> The id_token and access token have different semantics, and quite > > possable possibly formats. > > >> > > >> So the AT that comes with the id_token will be useful at RS > > associated with the AS, but it may not be useful at other API the > > client wants to access and that is generally where we run into the > > use case for token exchange. > > >> > > >> In the case of talking to a third party API it may be useful to > > have that API have a token exchange endpoint where a client can > > exchange a id_token/JWT for an access token. > > >> That is clearer and likely more secure given a confidential > > client than just using the id_token as a access token directly. > > >> > > >> Now I do understand people do that now. > > >> > > >> In the hopefully near future once we have token binding as a > > proof of possession mechanism it will be come clearer that you cant > > take a id_token that is bound to the browser presenting the token to > > the client and directly re use that as a secure access token. The > > AT and RT issued with that token will be bound to the client so that > > the RS can validate them. > > >> > > >> There are a lot of bad patterns possible with bearer tokens. I > > prefer to try to avoid them so that people will be in a better > > position when we move off bearer tokens for increased security. > > >> > > >> John B. > > >>> On Aug 4, 2016, at 11:17 AM, Sergey Beryozkin > > <[email protected] <mailto:[email protected]>> wrote: > > >>> > > >>> Hi Phil > > >>> > > >>> On 04/08/16 15:01, Phil Hunt (IDM) wrote: > > >>>> You might be munging two different flows with different > > semantics together. > > >>>> > > >>>> First flow is use oidc to authen the user to the client. > > >>>> > > >>>> Second flow is normal oauth authorization to get an at to > > access the resource. > > >>>> > > >>>> Often the OP AS is different from the RS's AS and the rs needs > > a proper "delegation" access token. > > >>> Indeed, this is more or less what I've been saying in our > > private discussions. > > >>> > > >>> But as I said to in my response to Mike, I see a demand to have > > IdToken propagated and given the token exchange draft has a > > dedicated 'impersonation' section I'm assuming there's a need for it. > > >>> > > >>> For example, I was checking the archives, could see Brian > > Campbell quoting Vittorio Bertocci: > > >>> "To summarize our main use case: we use [a token exchange like > > protocol] for achieving user impersonation thru tiers, or delegation > > for confidential clients which do not have any web UX..." > > >>> > > >>> The former case there suggests that if a client has a web UI > > they authenticate the user first and then start impersonating. > > >>> > > >>> I'm advocating for the clients to use the access tokens. The > > clients can requests the extra scopes while authenticating the user > > and if the user approves these scopes the client can continue using > > AT on behalf of the client, and using IdToken to only interact with > > the user. > > >>> > > >>> But I'm finding it difficult to explain (show a clear > > differentiator) when the client should use AT and when they should > > use IdToken to impersonate a user and get a new token (via the token > > exchange)... > > >>> > > >>> Sergey > > >>>> > > >>>> Phil > > >>>> > > >>>>> On Aug 4, 2016, at 6:00 AM, Mike Schwartz <[email protected] > > <mailto:[email protected]>> wrote: > > >>>>> > > >>>>> Sergey, > > >>>>> > > >>>>> Since no one answered your question, let me pose a few > > questions to your questions! > > >>>>> > > >>>>> Wouldn't it give you more flexibility to issue a different > > token to > > >>>>> represent access to the RS API? In terms of passing user > claims, > > >>>>> couldn't this be done via parameters in the API? Are you > > trying to do > > >>>>> more with OpenID Connect than was anticpiated in the design? > > >>>>> The id_token has an audience, are you including more than one > > client in that > > >>>>> audience? Would it make sense to look at token exchange and > > downscope the token? > > >>>>> If you are looking for a profile of OAuth2, might UMA work? > > >>>>> > > >>>>> I think you're not alone in wondering what the answer to all > > these questions are.. > > >>>>> > > >>>>> - Mike > > >>>>> > > >>>>> > > >>>>> ------------------------------------- > > >>>>> Michael Schwartz > > >>>>> Gluu > > >>>>> http://gluu.org > > >>>>> > > >>>>>> Message: 3 > > >>>>>> Date: Wed, 3 Aug 2016 11:08:29 +0100 > > >>>>>> From: Sergey Beryozkin <[email protected] > > <mailto:[email protected]>> > > >>>>>> To: "[email protected] <mailto:[email protected]>" <[email protected] > > <mailto:[email protected]>> > > >>>>>> Subject: [OAUTH-WG] Using IdToken instead of Access token > > >>>>>> Message-ID: <[email protected] > > <mailto:[email protected]>> > > >>>>>> Content-Type: text/plain; charset=windows-1252; format=flowed > > >>>>>> Hi All > > >>>>>> I hope this question is better suited for this list. Will > have no > > >>>>>> problems redirecting it to the openid-connect list instead. > > >>>>>> Consider a user working with the client web application (OIDC > > RP) which > > >>>>>> authenticates the user with the OIDC authorization code flow > > at the end > > >>>>>> of which the client gets AccessToken + IdToken. Next the user > > requests > > >>>>>> something from the client which needs to access the RS to > > complete this > > >>>>>> request. > > >>>>>> And the idea is to have the client pass IdToken to RS and use > > various > > >>>>>> user claims inside this IdToken to enforce the access control > > at the RS > > >>>>>> level. My position it is likely wrong but I guess I may be > > missing > > >>>>>> something that will be either in favor or against it. > > >>>>>> The reason I think it is wrong is that if the client is using > > a code > > >>>>>> flow then the right approach for staying within the OAuth2 > > 'world' is to > > >>>>>> use the access token to talk to RS and use IdToken only for > > the purpose > > >>>>>> of interacting with the user. The access token represents a > > proper user > > >>>>>> authorization and can have the extra scopes in addition to > > "oidc" which > > >>>>>> RS can depend upon in its access control restrictions. > > >>>>>> Next I'm arguing that if the IdToken is used instead then it > > is the case > > >>>>>> of the client impersonating the user. And refer to the STS > > for the REST > > >>>>>> of Us draft (I have a separate series of question on that > > draft). I'm > > >>>>>> saying the impersonation can work but ignoring the access > tokens > > >>>>>> completely will make the overall solution much less flexible. > > >>>>>> I'd like to ask for some advice/guidance: > > >>>>>> - Is it a good idea at all for the client to use IdToken > > instead of > > >>>>>> AccessToken as explored above ? I suppose it can work, in the > > code flow > > >>>>>> the client gets the access token which, by default, only > > allows to > > >>>>>> access UserInfo. Perhaps the client impersonating IdToken for > the > > >>>>>> purpose of accessing RS is not too bad after all. > > >>>>>> - Assuming the impersonation is OK, what is the right > > criteria for the > > >>>>>> client to choose to work with IdToken instead of the access > > token when > > >>>>>> accessing the immediate RS. It seems like if the > > impersonation is OK for > > >>>>>> the client to do then why have access tokens at all... > > >>>>>> - Assuming the impersonation is OK, does STS For the REST of > > Us shows > > >>>>>> the right and the only way it needs to be done ? I can > > imagine how it > > >>>>>> will work for the web app clients, but what about Implicit > > Clients. > > >>>>>> Many thanks, Sergey > > >>>>> > > >>>>> _______________________________________________ > > >>>>> OAuth mailing list > > >>>>> [email protected] <mailto:[email protected]> > > >>>>> https://www.ietf.org/mailman/listinfo/oauth > > >>>> > > >>>> _______________________________________________ > > >>>> OAuth mailing list > > >>>> [email protected] <mailto:[email protected]> > > >>>> https://www.ietf.org/mailman/listinfo/oauth > > >>>> > > >>> > > >>> > > >>> -- > > >>> Sergey Beryozkin > > >>> > > >>> Talend Community Coders > > >>> http://coders.talend.com/ > > >>> > > >>> _______________________________________________ > > >>> OAuth mailing list > > >>> [email protected] <mailto:[email protected]> > > >>> https://www.ietf.org/mailman/listinfo/oauth > > >> > > > > > > > > > -- > > > Sergey Beryozkin > > > > > > Talend Community Coders > > > http://coders.talend.com/ > > > > _______________________________________________ > > OAuth mailing list > > [email protected] <mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/oauth > > > > -- > > > > Nat Sakimura > > > > Chairman of the Board, OpenID Foundation > > > > -- Nat Sakimura Chairman of the Board, OpenID Foundation
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
