Re: [OAUTH-WG] feedback on draft-ietf-oauth-browser-based-apps-00

[George Fletcher]

I think it's fair to call it out (either in the paragraph here or in the 
security considerations). The issue is that the security aspect of the 
access token ending up in the browser is probably true in many contexts 
other than SPAs:)


What about something like...

In this scenario, the backend component is likely a confidential client 
which is issued it's own client secret. Note that in this model, the 
access_token obtained by the backend component will be delivered to the 
browser for use by the SPA so is more exposed than in the classic 
confidential client model. Some Authorization Servers may wish to limit 
the capabilities of these clients due to risk considerations.


 or something like that.

On 4/2/19 11:57 AM, Aaron Parecki wrote:
Thanks, this is a good question. I was talking with someone about this 
draft the other day and had the same question myself. Re-reading 
RFC6749, "public client" does describe only the limitation of the 
client protecting its own credentials, so I think you're right that 
this paragraph is misleading. However I suspect that some ASs will 
still want to treat clients where the access token ends up in the 
browser differently. Is that a fair assessment? I think the fix to 
this paragraph would be a slight rewording to just remove the mention 
of public clients.


Aaron


On Tue, Apr 2, 2019 at 8:53 AM George Fletcher > wrote:


Hi,

In section 6.2 the following statement is made...

In this scenario, the backend component may be a confidential client
which is issued its own client secret.  Despite this, there are still
some ways in which this application is effectively a public client,
as the end result is the application's code is still running in the
browser and visible to the user.


I'm curious as to how this model is different from many existing
resource server deployments acting as confidential clients. While
the application code is running in the browser, only the access
token is exposed to the browser as is the case for many RS
deployments where the RS returns the access token to the browser
after the authorization flow completes. My interpretation of
"confidential client" does not include whether the client's code
is "visible" to externals or not, but rather whether the client
can protect the secret.

In that sense I don't believe this deployment model is
"effectively a public client". A hybrid model description is fine,
and I don't disagree that some authorization servers may want to
treat these clients in a different way.

Thanks,
George

--

Aaron Parecki
aaronparecki.com 
@aaronpk 



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] feedback on draft-ietf-oauth-browser-based-apps-00

[Aaron Parecki]

Thanks, this is a good question. I was talking with someone about this
draft the other day and had the same question myself. Re-reading RFC6749,
"public client" does describe only the limitation of the client protecting
its own credentials, so I think you're right that this paragraph is
misleading. However I suspect that some ASs will still want to treat
clients where the access token ends up in the browser differently. Is that
a fair assessment? I think the fix to this paragraph would be a slight
rewording to just remove the mention of public clients.

Aaron


On Tue, Apr 2, 2019 at 8:53 AM George Fletcher  wrote:

> Hi,
>
> In section 6.2 the following statement is made...
>
>In this scenario, the backend component may be a confidential client
>which is issued its own client secret.  Despite this, there are still
>some ways in which this application is effectively a public client,
>as the end result is the application's code is still running in the
>browser and visible to the user.
>
>
> I'm curious as to how this model is different from many existing resource
> server deployments acting as confidential clients. While the application
> code is running in the browser, only the access token is exposed to the
> browser as is the case for many RS deployments where the RS returns the
> access token to the browser after the authorization flow completes. My
> interpretation of "confidential client" does not include whether the
> client's code is "visible" to externals or not, but rather whether the
> client can protect the secret.
>
> In that sense I don't believe this deployment model is "effectively a
> public client". A hybrid model description is fine, and I don't disagree
> that some authorization servers may want to treat these clients in a
> different way.
>
> Thanks,
> George
>
-- 

Aaron Parecki
aaronparecki.com
@aaronpk 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] feedback on draft-ietf-oauth-browser-based-apps-00

[George Fletcher]

Hi,

In section 6.2 the following statement is made...

   In this scenario, the backend component may be a confidential client
   which is issued its own client secret.  Despite this, there are still
   some ways in which this application is effectively a public client,
   as the end result is the application's code is still running in the
   browser and visible to the user.


I'm curious as to how this model is different from many existing 
resource server deployments acting as confidential clients. While the 
application code is running in the browser, only the access token is 
exposed to the browser as is the case for many RS deployments where the 
RS returns the access token to the browser after the authorization flow 
completes. My interpretation of "confidential client" does not include 
whether the client's code is "visible" to externals or not, but rather 
whether the client can protect the secret.


In that sense I don't believe this deployment model is "effectively a 
public client". A hybrid model description is fine, and I don't disagree 
that some authorization servers may want to treat these clients in a 
different way.


Thanks,
George
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-fett-oauth-dpop-00

[Brian Campbell]

Except that the jwk header is more appropriate in the given context
https://tools.ietf.org/html/rfc7515#section-4.1.3 - it is the public key
that corresponds to the key used to digitally sign the JWS.  Which is what
it is.



On Thu, Mar 28, 2019, 6:32 AM Mike Jones  wrote:

> Good observation, Ludwig.  We should do that.
>
> -- Mike
>
> -Original Message-
> From: OAuth  On Behalf Of Ludwig Seitz
> Sent: Thursday, March 28, 2019 12:05 PM
> To: oauth@ietf.org
> Subject: Re: [OAUTH-WG] draft-fett-oauth-dpop-00
>
> On 28/03/2019 11:17, Daniel Fett wrote:
> > Hi all,
> >
> > I published the first version of the DPoP draft at
> > https://tools.ietf.org/html/draft-fett-oauth-dpop-00
> >
> > Abstract
> >
> > This document defines a sender-constraint mechanism for OAuth 2.0
> > access tokens and refresh tokens utilizing an application-level
> > proof-of-possession mechanism based on public/private key pairs.
> >
> >
> > Thanks for the feedback I received so far from John, Mike, Torsten,
> > and others during today's session or before!
> >
> > If you find any errors I would welcome if you open an issue in the
> > GitHub repository at https://github.com/webhamster/draft-dpop
> >
> > - Daniel
> >
> >
>
> A quick nit:
>
> in figure 3 you seem to be using the "jwk" claim to include the pop-key in
> the token. Any reason for not using the "cnf" claim from RFC 7800?
>
> /Ludwig
>
>
> --
> Ludwig Seitz, PhD
> Security Lab, RISE
> Phone +46(0)70-349 92 51
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth