Hi Prateek
On 20/05/14 16:00, Prateek Mishra wrote:
Sergey - you haven't missed anything. The client remains unregistered
throughout the exchange.
There is no relationship between the assertion grant (or access token)
and the client either.
You are pointing out that an AS endpoint supporting unregistered clients
(public in OAuth terminology) for
exchanging assertion grants --> access tokens is open to several
security attacks. The simplest is that the
assertion grant could be stolen/forwarded to some malicious third party
which could use it to obtain a token
and then use it for resource access.
As I understand it, the security model depends on the Out-of-Band
relationship between the client and the local STS
that provided the client with the initial token (assertion grant). The
idea is that the AS endpoint trusts the local
STS, and hopes that the STS would not provide the assertion grant to a
"bad" client.
I would not recommend the use of this model for anything substantive.
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 <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/__listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
