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. Best, Nat 2016年8月5日(金) 5:58 John Bradley <ve7...@ve7jtb.com>: > 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 <sberyoz...@gmail.com> > 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 <sberyoz...@gmail.com> > 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 <m...@gluu.org> 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 <sberyoz...@gmail.com> > >>>>>> To: "oauth@ietf.org" <oauth@ietf.org> > >>>>>> Subject: [OAUTH-WG] Using IdToken instead of Access token > >>>>>> Message-ID: <b026f4fc-3e08-4e00-02c3-84be2dc4b...@gmail.com> > >>>>>> 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 > >>>>> OAuth@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>> > >>>> _______________________________________________ > >>>> OAuth mailing list > >>>> OAuth@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/oauth > >>>> > >>> > >>> > >>> -- > >>> Sergey Beryozkin > >>> > >>> Talend Community Coders > >>> http://coders.talend.com/ > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >> > > > > > > -- > > Sergey Beryozkin > > > > Talend Community Coders > > http://coders.talend.com/ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Nat Sakimura Chairman of the Board, OpenID Foundation
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
