Hi
On 21/05/14 03:29, Prateek Mishra wrote:
The difference between the two scenarios is that the authorization code
has a one-use property and also requires the user to be present.
These conditions are not available in the (assertion grant --> access
token) with a public client. So there are some fundamental differences
in security properties between the two.
In terms of stronger bindings, I think the PoP work would provide a
better model for a public client presenting a SAML/JWT assertion. Key
confirmation would ensure that no other client could present the
assertion to the AS.
Nice, thanks for the analysis,
May be bearer assertions drafts should have text recommending AS to
enforce a one time use condition too for public clients using assertions
as grants, based on the assertion id, seems like it won't harm,
Cheers, Sergey
Thanks, it actually helps, I realized it is exactly the same case
(very similar to it) where an unregistered/public client gets an
authorization code securely entered by the end user who has securely
authorized a public client. Next this public client exchanges a code
grant for a token and AS optionally accepts by trusting that the end
user has securely entered a code into the mobile device/etc...
I guess the risk of the assertion being stolen might be minimized by
keeping an access token lifespan to a very short period of time...
I wonder can the assertion grant have a stronger binding to the
unregistered clients somehow...
Cheers, Sergey
- prateek
What confuses me still is this: given a grant (whatever grant it is)
AS issues a token which is associated with a given client somehow.
When a registered client uses JWT or SAML assertion to authenticate it
is all clear (I can imagine the client logs on to STS, gets the
assertion and authenticates with it to AS).
Now if we have an unregistered client using an assertion grant, how do
we associate a token with this unregistered client, the text seems to
imply that the assertion grant does not identify this unregistered
client either, so it is not clear how this client can use the token
afterwards, even though AS can validate with STS/etc that the grant is
valid.
Is the idea that the registration happens after the unregistered
client has exchanged an assertion grant for a token ?
Sorry, I know I'm missing something obvious here...
Thanks, Sergey
On Thu, May 15, 2014 at 10:41 AM, Sergey Beryozkin
<sberyoz...@gmail.com
<mailto:sberyoz...@gmail.com>> wrote:
Hi
I'm reviewing the way client authentication is expected to be done
when either SAML or JWT bearer assertion is used as a grant [1]
which corresponds to the case described in [2].
[1] says: "Authentication of the client is optional...".
Can someone please clarify how it can be optional given that in
this
case a subject of the assertion does not identify a client ? Is it
about supporting unregistered clients which have managed to obtain
somehow the assertion grants ?
Thanks, Sergey
[1]
http://tools.ietf.org/html/__draft-ietf-oauth-assertions-__16#section-4.1
<http://tools.ietf.org/html/draft-ietf-oauth-assertions-16#section-4.1>
[2]
http://tools.ietf.org/html/__draft-ietf-oauth-assertions-__16#section-6.3
<http://tools.ietf.org/html/draft-ietf-oauth-assertions-16#section-6.3>
_________________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/__listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
