Subject: [OAUTH-WG] Client authentication and assertion grants

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 15 May 2014 17:41:43 +0100

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
[2] http://tools.ietf.org/html/draft-ietf-oauth-assertions-16#section-6.3

---

From: Brian Campbell <[email-masked]>
Date: Tue, 20 May 2014 07:03:22 -0600

Yes Sergey, it's to allow for support of unregistered clients. Typically
such clients will have some relationship established with a security token
service (STS) where they can obtain assertion grants and the AS trusts the
STS to issue such assertions. In that kind of scenario, the identity of the
client can be considered unimportant - what's important is that the AS
trusts the STS and in turn the STS trusted the client enough to issues it a
suitable assertion.

On Thu, May 15, 2014 at 10:41 AM, Sergey Beryozkin <[email-masked]>wrote:

> 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
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 20 May 2014 15:04:20 +0100

Hi,

Thanks for the clarification,
On 20/05/14 14:03, Brian Campbell wrote:
> such clients will have some relationship established with a security
> token service (STS) where they can obtain assertion grants and the AS
> trusts the STS to issue such assertions. In that kind of scenario, the
> identity of the client can be considered unimportant - what's important
> is that the AS trusts the STS and in turn the STS trusted the client
> enough to issues it a suitable assertion.

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-masked]
> <mailto:[email-masked]>> 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].
>
>     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-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/oauth
>     <https://www.ietf.org/mailman/listinfo/oauth>
>
>

---

From: Bill Burke <[email-masked]>
Date: Tue, 20 May 2014 10:15:37 -0400

> Sorry, I know I'm missing something  obvious here...

The unregistered client could, out-of-band, get its own token with the 
appropriate claims.  The unregistered client would use this token as a 
credential when asking for an access token.

I think what this setup allows you to do is to have a federated set of 
STS services.  Where one STS deals with providing access tokens for 
applications and another deals with providing access tokens for clients 
to access application STS services :)  Instead of just one auth server 
having to know about everything, you can delegate things to different 
servers.

Am I on the right track?

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

---

From: Prateek Mishra <[email-masked]>
Date: Tue, 20 May 2014 08:00:57 -0700

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.

- 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.
>
> Is the idea that the registration happens after the unregistered 
> client has exchanged an assertion grant for a token ?
>

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 20 May 2014 22:58:32 +0100

Hi Prateek
> 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

---

From: Prateek Mishra <[email-masked]>
Date: Tue, 20 May 2014 19:29:38 -0700

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.

>
>>
> 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...
>

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 21 May 2014 11:01:49 +0100

Hi
> confirmation would ensure that no other client could present the

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