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
