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]> 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]> 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]>
To: "[email protected]" <[email protected]>
Subject: [OAUTH-WG] Using IdToken instead of Access token
Message-ID: <[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]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
