Subject: [OAUTH-WG] CORS and public vs. confidential clients

From: Bill Burke <[email-masked]>
Date: Thu, 27 Mar 2014 11:30:15 -0400

I'm still trying to wrap my head around the differences between public 
and confidential clients.  In our IDP impl, we check redirect uris and 
associate a lot of private metadata to the access code to ensure there 
is no client_id swapping.  My understanding was that confidential 
clients made sure that only an authenticated client could obtain an 
access token.

What if you throw CORS in the mix where your browser needs the access 
token (and the ability to refresh it) to make cross-domain requests? 
Doesn't this remove a large benefit of confidential clients?

Anybody know a good document that describes the difference and pros/cons 
of public vs. confidential clients beyond the actual OAUTH spec itself?

Thanks

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

---

From: Phil Hunt <[email-masked]>
Date: Thu, 27 Mar 2014 12:00:22 -0700

Bill,

I can't comment to how effective your use of "private metadata" is to supporting effective authentication of clients. If you feel it is sufficient than you could classify them as "confidential" since you are authenticating based on the metadata.  

I also can't comment on CORS as I am not familiar with it.

I would take a look at the Threat Model (RFC 6819) in addition to 6749 and 6750 to get a better idea of the many issues - particularly with browsers that are faced.

Phil

@independentid
www.independentid.com
[email-masked]

On 2014-03-27, at 8:30 AM, Bill Burke <[email-masked]> wrote:

> I'm still trying to wrap my head around the differences between public and confidential clients.  In our IDP impl, we check redirect uris and associate a lot of private metadata to the access code to ensure there is no client_id swapping.  My understanding was that confidential clients made sure that only an authenticated client could obtain an access token.
> 
> What if you throw CORS in the mix where your browser needs the access token (and the ability to refresh it) to make cross-domain requests? Doesn't this remove a large benefit of confidential clients?
> 
> Anybody know a good document that describes the difference and pros/cons of public vs. confidential clients beyond the actual OAUTH spec itself?
> 
> Thanks
> 
> -- 
> Bill Burke
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Prateek Mishra <[email-masked]>
Date: Thu, 27 Mar 2014 16:59:55 -0700

Bill - as you are referencing CORS in your message, I assume you are 
discussing a Javascript-only (browser) client. I believe the implicit flow
was designed for this case and this flow never involves a confidential 
client.

Confidential clients may be used with the other flows (code, 
resource,..) that are capable of making a TLS call to a Token Endpoint.

- prateek

> Anybody know a good document that describes the difference and 
> pros/cons of public vs. confidential clients beyond the actual OAUTH 
> spec itself?
>
> Thanks
>

---

From: Bill Burke <[email-masked]>
Date: Fri, 28 Mar 2014 12:51:57 -0400

The thread model doc was really great, but I still couldn't find 
anything concrete on what guarantees you lose if you use a public client 
vs. a confidential one.  Honestly, I'm just trying to have the right 
info to guide users on what auth flow to use and the pros/cons.

> was designed for this case and this flow never involves a confidential
Yes, it is a Javascript (browser) client.  Implicit flow doesn't allow 
for a refresh token.  Our browser javascript code uses CORS also when 
participating in the access code grant flow.

Our access codes are digitally signed, and unique.  They can only be 
turned into an access token once.  They are associated privately with a 
redirect URI, state, and client_id.  And they have a timeout.  We do 
validation/verification at each part of the flow to make sure the 
redirectURI, state, and/or client_id is valid.  I just want to know what 
to tell users what security implications there are if they use a public 
client in this scenario.

> resource,..) that are capable of making a TLS call to a Token Endpoint.

BTW, Is there a better list for these types of questions?  Didn't have a 
lot of luck on the Google Group for OAuth.