[OAUTH-WG] OAuth Security -- Next Steps

Sounds about right, but I would imagine that the BCP would cover any issue that arises not just mix-up

-----Original Message-----
From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Monday, July 25, 2016 3:59 AM
To: ***@ietf.org
Subject: [OAUTH-WG] OAuth Security -- Next Steps

Hi all,

We had two working group sessions at the Berlin IETF meeting and I am happy about the progress on many of the subjects. We managed to progress token exchange, native apps, AMR, and authorization server meta-data. We also identified new use cases to explore with the device flow document.

We also did a call for adoption of the OAuth token binding functionality, which still needs to be confirmed on the mailing list.
(Further emails will follow.)

There are, however, aspects I am not happy with. I was hoping to make some progress on the mix-up mitigation and on the wider range of security documents.

Here is how I see the story after talking to some meeting participants.

1) It seems that the solution approach to deal with the mix-up attack (only mix-up) described in draft-ietf-oauth-mix-up-mitigation-01 needs to be modified to reflect the preference of the working group. My impression (from speaking with participants at the meeting last week
privately) is that there is interest in a solution that does not require protocol changes but rather relies on configuration. This may include a combination of exact redirect_URI matching + per-AS redirect_URI + session state checking. There are also other attacks described in draft-ietf-oauth-mix-up-mitigation-01, which need to be moved elsewhere to avoid confusion.

2) We need a new document, ideally a BCP, that serves as a high-level write-up describing various security issues with OAuth that points to the mostly existing documents for those who want to read the background information. Torsten has posted a mail to the list providing one possible outline of such a document.

How does this sound?

Ciao
Hannes

Brian Campbell

2016-07-27 21:53:35 UTC

Agree. The BCP would be larger in scope than just mix-up. And given that
approach, I don't know if it makes sense to have a document specific to
mix-up.

Post by Anthony Nadalin
Sounds about right, but I would imagine that the BCP would cover any issue
that arises not just mix-up
-----Original Message-----
Sent: Monday, July 25, 2016 3:59 AM
Subject: [OAUTH-WG] OAuth Security -- Next Steps
Hi all,
We had two working group sessions at the Berlin IETF meeting and I am
happy about the progress on many of the subjects. We managed to progress
token exchange, native apps, AMR, and authorization server meta-data. We
also identified new use cases to explore with the device flow document.
We also did a call for adoption of the OAuth token binding functionality,
which still needs to be confirmed on the mailing list.
(Further emails will follow.)
There are, however, aspects I am not happy with. I was hoping to make some
progress on the mix-up mitigation and on the wider range of security
documents.
Here is how I see the story after talking to some meeting participants.
1) It seems that the solution approach to deal with the mix-up attack
(only mix-up) described in draft-ietf-oauth-mix-up-mitigation-01 needs to
be modified to reflect the preference of the working group. My impression
(from speaking with participants at the meeting last week
privately) is that there is interest in a solution that does not require
protocol changes but rather relies on configuration. This may include a
combination of exact redirect_URI matching + per-AS redirect_URI + session
state checking. There are also other attacks described in
draft-ietf-oauth-mix-up-mitigation-01, which need to be moved elsewhere to
avoid confusion.
2) We need a new document, ideally a BCP, that serves as a high-level
write-up describing various security issues with OAuth that points to the
mostly existing documents for those who want to read the background
information. Torsten has posted a mail to the list providing one possible
outline of such a document.
How does this sound?
Ciao
Hannes
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

Vladimir Dzhuvinov

2016-07-28 07:56:03 UTC

I congratulate the idea for a BCP.

Ideally that would be a document written with the developer in mind,
easy to consume, and outlining all necessary steps to take in order to
harden / patch up an OAuth 2.0 implementation / app. The individual
attacks could be referenced or described in an appendix.

Working from documents that describe an individual attack, or a class of
attacks, where a matching countermeasure is suggested, is harder for
developers (the typical format of security research papers). In
conversations with developers I found out that many of them have indeed
read about the recently discovered problems, but don't have a good
picture of the overall situation, and how to react. Therefore, putting
together a clear course for action, sanctioned by the OAuth WG, would be
really useful.

I also imagine the BCP could suggest two variants for action:

1. For those people who have existing apps in the field, and mostly 3rd
party client developers. They will probably be looking for the minimum
amount of measures to secure their OAuth 2.0 stuff, to minimise
disruption and all sorts of hassle related to updating APIs, clients,
libraries, etc.

2. For people who want to have additional protections to OAuth 2.0 in
place, e.g. JWT assertions for client auth, bound tokens, etc. Typically
companies that are in control of their clients and apps, or those that
consider introducing OAuth 2.0 for the first time.

Thanks,

Vladimir

Post by Brian Campbell
Agree. The BCP would be larger in scope than just mix-up. And given that
approach, I don't know if it makes sense to have a document specific to
mix-up.

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

Sergey Beryozkin

2016-08-03 10:08:29 UTC

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

Mike Schwartz

2016-08-04 13:00:03 UTC

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
Subject: [OAUTH-WG] Using IdToken instead of Access token
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.
- 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

Phil Hunt (IDM)

2016-08-04 14:01:05 UTC

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

Post by Mike Schwartz
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
Subject: [OAUTH-WG] Using IdToken instead of Access token
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.
- 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
https://www.ietf.org/mailman/listinfo/oauth

Sergey Beryozkin

2016-08-04 15:17:36 UTC

Hi Phil

Post by Phil Hunt (IDM)
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

Message: 3
Date: Wed, 3 Aug 2016 11:08:29 +0100
Subject: [OAUTH-WG] Using IdToken instead of Access token
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.
- 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
https://www.ietf.org/mailman/listinfo/oauth

--
Sergey Beryozkin

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

Phil Hunt (IDM)

2016-08-04 15:48:18 UTC

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

Post by Sergey Beryozkin
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.
"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

Message: 3
Date: Wed, 3 Aug 2016 11:08:29 +0100
Subject: [OAUTH-WG] Using IdToken instead of Access token
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.
- 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
https://www.ietf.org/mailman/listinfo/oauth

--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

Sergey Beryozkin

2016-08-04 16:22:49 UTC

Post by Phil Hunt (IDM)
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.

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

Post by Sergey Beryozkin
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.
"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

Message: 3
Date: Wed, 3 Aug 2016 11:08:29 +0100
Subject: [OAUTH-WG] Using IdToken instead of Access token
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.
- 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
https://www.ietf.org/mailman/listinfo/oauth

--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

John Bradley

2016-08-04 16:04:26 UTC

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.

Post by Sergey Beryozkin
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.
"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

Message: 3
Date: Wed, 3 Aug 2016 11:08:29 +0100
Subject: [OAUTH-WG] Using IdToken instead of Access token
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.
- 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
https://www.ietf.org/mailman/listinfo/oauth

--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

Sergey Beryozkin

2016-08-04 16:26:48 UTC

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

Post by John Bradley
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.

Post by Sergey Beryozkin
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.
"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

Message: 3
Date: Wed, 3 Aug 2016 11:08:29 +0100
Subject: [OAUTH-WG] Using IdToken instead of Access token
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.
- 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
https://www.ietf.org/mailman/listinfo/oauth

--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

--
Sergey Beryozkin

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

John Bradley

2016-08-04 20:58:20 UTC

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.

Post by Sergey Beryozkin
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

Post by Sergey Beryozkin
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.
"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

Message: 3
Date: Wed, 3 Aug 2016 11:08:29 +0100
Subject: [OAUTH-WG] Using IdToken instead of Access token
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.
- 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
https://www.ietf.org/mailman/listinfo/oauth

--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/

Nat Sakimura

2016-08-05 10:16:49 UTC

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

Post by John Bradley
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.

Post by Sergey Beryozkin
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

Post by Sergey Beryozkin
Thanks, Sergey

Post by John Bradley
The id_token and access token have different semantics, and quite

possable possibly formats.

Post by John Bradley
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.

Post by John Bradley
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.

Post by John Bradley
That is clearer and likely more secure given a confidential client

than just using the id_token as a access token directly.

Post by John Bradley
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.

Post by John Bradley
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.