Subject: Re: [OAUTH-WG] Using IdToken instead of Access token

From: Mike Schwartz <[email-masked]>
Date: Thu, 04 Aug 2016 08:00:03 -0500

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-masked]>
> To: "[email-masked]" <[email-masked]>
> Subject: [OAUTH-WG] Using IdToken instead of Access token
> Message-ID: <[email-masked]>
> 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
> 
> 
>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Thu, 4 Aug 2016 07:01:05 -0700

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. 

Phil

> On Aug 4, 2016, at 6:00 AM, Mike Schwartz <[email-masked]> wrote:
> 
> Sergey,
> 
> Since no one answered your question, let me pose a few questions to your questions!
> 
> 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?
> I think you're not alone in wondering what the answer to all these questions are..
> 
> - Mike
> 
> 
>> flow then the right approach for staying within the OAuth2 'world' is to
>> Next I'm arguing that if the IdToken is used instead then it is the case
>> accessing the immediate RS. It seems like if the impersonation is OK for
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 4 Aug 2016 16:00:07 +0100

Hi Mike

On 04/08/16 14:00, Mike Schwartz wrote:
> represent access to the RS API?

If you refer to the fact that in the code flow the client gets both 
AccessToken and IdToken with the former to be used to access the RS API 
then indeed this is what I'm advocating.

But I see in our internal discussions that the desire to use IdToken 
instead is strong and I'm finding I'm lacking some arguments to explain 
why using AT should be preferable and when the user impersonation by the 
client is acceptable then what is the right way to do it (I think it is 
the token exchange draft, the impersonation case).

> In terms of passing user claims,
> couldn't this be done via parameters in the API?
No
> Are you trying to do
This is what I'm saying that OIDC is primarily about the client 
authenticating the user and the access token returned as part of the 
OIDC code flow can be used by the client to continue working with the 
chained RSs on behalf of this user
> audience? Would it make sense to look at token exchange and downscope
Yes, I suppose this is what we should do
> If you are looking for a profile of OAuth2, might UMA work?
Haven't thought about it yet
> I think you're not alone in wondering what the answer to all these
Thanks, Sergey

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 4 Aug 2016 16:17:36 +0100

Hi Phil

> 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

-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Thu, 4 Aug 2016 08:48:18 -0700

This is as bad as assuming an access token means someone was authenticated. 

In this case the audience of the id token is not the resource and other badness may ensue. 

Phil

> On Aug 4, 2016, at 8:17 AM, Sergey Beryozkin <[email-masked]> wrote:
> 
> Hi Phil
> 
> 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
>>

---

From: John Bradley <[email-masked]>
Date: Thu, 4 Aug 2016 12:04:26 -0400

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-masked]> wrote:
> 
> Hi Phil
>

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 4 Aug 2016 17:22:49 +0100

> In this case the audience of the id token is not the resource and other badness may ensue.

I'm not sure what this comment is related to.

Did you see what I'm asking about ? I'm repeating that I'm not 
advocating to use IdTokens as AccessTokens; IdTokens are for the client 
to interact with the user, AccessTokens are for the client to access RS 
on behalf of the user.

But there's a token exchange draft having a section on the 
impersonation. There must be a reason it is there. Trying to figure
how it is related to the well known tokens (IdToken, AccessToken)

Sergey

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 4 Aug 2016 17:26:48 +0100

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

-- 
Sergey Beryozkin

Talend Community Coders

---

From: John Bradley <[email-masked]>
Date: Thu, 4 Aug 2016 16:58:20 -0400

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-masked]> 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
>

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 05 Aug 2016 10:16:49 +0000

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 <[email-masked]>:

> 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.
> 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.
>
> >> 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.
> >>
> >> 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.
> >>> 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
> >>> "To summarize our main use case: we use [a token exchange like
> protocol] for achieving user impersonation thru tiers, or delegation for
> >>> 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
-- 

Nat Sakimura

Chairman of the Board, OpenID Foundation

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 5 Aug 2016 12:14:11 +0100

Hi John

> For token exchange we wanted to be more explicit so that the client has more control over the exchange.

It does.
Cheers, Sergey

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 5 Aug 2016 12:20:43 +0100

Hi Nat
On 05/08/16 11:16, Nat Sakimura wrote:
> 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-masked]
> <mailto:[email-masked]>>:
>
>     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.
>     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.
>
>     > On Aug 4, 2016, at 12:26 PM, Sergey Beryozkin
>     <[email-masked] <mailto:[email-masked]>> 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
>     >
>     >> 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.
>     >>
>     >> 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-masked] <mailto:[email-masked]>> wrote:
>     >>>
>     >>> Hi Phil
>     >>>
>     IdToken propagated and given the token exchange draft has a
>     dedicated 'impersonation' section I'm assuming there's a need for it.
>     >>>
>     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-masked]
>     <mailto:[email-masked]>> wrote:
>     >>>>>
>     >>>>> Sergey,
>     >>>>>
>     >>>>>> From: Sergey Beryozkin <[email-masked]
>     <mailto:[email-masked]>>
>     >>>>>> To: "[email-masked] <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>
>     >>>>>> Message-ID: <[email-masked]
>     <mailto:[email-masked]>>
>     >>>>> [email-masked] <mailto:[email-masked]>
>     >>>> [email-masked] <mailto:[email-masked]>
>     >>> [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 05 Aug 2016 14:46:54 +0000

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.

Nat Sakimura