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
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
