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

[David Waite]

Multiple concepts often get tacked onto a particular term, which both aids and 
hinders communication.

From RFC 6749, a public client is defined as:
 "Clients incapable of maintaining the confidentiality of their
  credentials (e.g., clients executing on the device used by the
  resource owner, such as an installed native application or a web
  browser-based application), and incapable of secure client
  authentication via any other means.”

RFC 6749 also defines a user-agent-based application:
   " A user-agent-based application is a public client in which the
  client code is downloaded from a web server and executes within a
  user-agent (e.g., web browser) on the device used by the resource
  owner.  Protocol data and credentials are easily accessible (and
  often visible) to the resource owner.  Since such applications
  reside within the user-agent, they can make seamless use of the
  user-agent capabilities when requesting authorization.”

These have over time been conflated. So when people speak of public clients, 
they may mean a client which has some subset of the following aspects:
- A client which is also a user agent (I personally consider native 
applications to also be a user agent, but that’s neither here nor there)
- A client that cannot keep a secret and thus cannot be issued a secret
- A lack of guarantee that the client represents a particular agent (that it is 
unmodified 1st or 3rd party code)
- A client that cannot keep access tokens and traffic confidential (even if 
that is from a creative resource owner)

The ability to keep a secret is perhaps the least meaningful part of this list. 
The secret serves a purpose to identify the client, and thus “know” access 
tokens are being requested by that client. It isn’t that public clients cannot 
hold a secret that matters - it is that they cannot be reliably identified or 
assumed authentic.

In the confidential client case, the client is expected to represent particular 
business goals and possibly a particular organizational relationship. The 
access token is confidential, the communication with the resources is 
confidential - driven by business logic which is meant to be fixed to represent 
those business goals.

In a public client, the security model can try to defend against malicious 
third parties like web attackers and malicious parties acting as other clients, 
authorization servers, or protected resources - but you can’t defend against a 
compromised platform or a sufficiently motivated end user. 

Since a hybrid sharing of tokens between the two is not defined by any 
specification, we can only assume things like:
- either the backend gives the front-end an access token, another token which 
acts equivalent to the access token, or sets a cookie value which when applied 
to resources acts equivalent to an access token
- this means while the backend can keep a secret, it is meaningless in that the 
access token rights gained from that secret are not confidential
- since the frontend initiates the protocol traffic and has this new 
credential, the protocol data and which actions are performed are not secured

Now if this backend exposes its own reduced resource server and its own tokens, 
then this is different - but then I would argue either that:
- conceptually the backend is now the new AS and resource server for my 
frontend, which is still a public client (but perhaps no longer a public client 
in the eyes of the original AS)
- or that this is no longer OAuth

-DW

> On Apr 2, 2019, at 9:52 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

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

[OAUTH-WG] DPoP blog post

[Mike Jones]

FYI, I posted about the new DPoP draft at http://self-issued.info/?p=1967 and 
as @selfissued, asking people to have a look 
and provide feedback.

   -- Mike


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

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

[Hans Zandbelt]

I will argue that in a way such deployments are already broken e.g. in the
typical use case of onboarding client accounts in the same
directory/OU/namespace as user accounts and we don't need to cater for that..

Hans.

On Wed, Apr 3, 2019 at 10:48 PM George Fletcher  wrote:

> I agree that this will break a lot of existing flows... especially those
> using any form of the client_credentials flow. In that sense I'm not
> completely on board yet :)
>
> On 3/26/19 12:56 PM, Hans Zandbelt wrote:
>
> great summary! this will hurt quite a few existing m2m deployments but I
> do like the rigidness of it all: it is very explicit, cannot misinterpreted
> and thus prevents failure (which is really what Dominick is after); I'm on
> board
>
> Hans.
>
> On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci  40auth0@dmarc.ietf.org> wrote:
>
>> thank you Steinar and everyone else for the comments on this!
>> To summarize the situation so far: Dominick, Steinar, Rob, David, Nov,
>> Bertrand recommend using sub only for users. Martin would like to have the
>> sub for app only flows as well. Hans is neutral.
>> That does sound like the sub as user has more consensus, tho before
>> changing it I'd wait for the people currently at IETF104 to have more time
>> to comment as well.
>> Clarification. If the goal is to be able to apply the logic "if there's a
>> sub, it's a user flow", we have to explicitly disallow (MUST NOT) the use
>> of sub when that's not the case. Are all OK with it?
>>
>> Dave, the suggestion of having explicit typing for app only vs user only
>> is interesting! For the purpose of putting together an interoperable
>> profile, tho, I would suggest we table it for v1 in the interest of getting
>> to something easy to adopt (hence with small delta vs existing
>> implementations) faster.
>>
>> On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem  wrote:
>>
>>> Hi Vittorio, we  (the national federation-gateway for the health
>>> services in norway - "HelseID")  think his is a really valuable initiative!
>>> We also agree with Dominick concerning definition of the "sub" claim.
>>>
>>> Steinar
>>>
>>> tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier <
>>> dba...@leastprivilege.com>:
>>>
 From an access token consumer (aka API) developer point of view, I
 prefer this logic

 "If sub is present - client acts on behalf of a user, if not - not."

 Anything more complicated has a potential of going wrong.


 On 26. March 2019 at 01:34:53, Nov Matake (mat...@gmail.com) wrote:

 Hi Vittorio,

 Yeah, I’m concerning user & client ids collision.
 I haven’t seen such implementations, but user-select username as sub,
 or incremental integer as sub & client_id will be easily collide.

 If you can enforce collision resistant IDs between user & client
 instances, it’ll works fine. I feel its overkill though.

 Sent from my iPhone

 On Mar 26, 2019, at 8:51, Vittorio Bertocci  wrote:

 Hey Nov, Dominick, Hans-
 thanks for the comments. That was an area I was expecting to cause more
 discussion, and I am glad we are having this opportunity to clarify.
 The current language in the draft traces the etymology of sub to OpenID
 Connect core, hence Dominick observation is on point. However in the
 description I express something in line with 7519, which was in fact my
 intent.

 The idea was to provide an identifier of the calling subject that is
 guaranteed to be present in all cases- this would allow an SDK developer to
 use the same code for things like lookups and membership checks regardless
 of the nature of the caller (user in a delegated case, app in app-only
 grants). The information to discriminate between user and app callers is
 always available in the token (say, the caller is a user if sub!=client_id,
 where client_id is always guaranteed to be present as well) hence there's
 no loss in expressive power, should that difference be relevant for the
 resource server.

 Dominick, Hans- I probably missed the security issue you guys are
 thinking of in this case. Of course, if this would introduce a risk I
 completely agree it should be changed- I'd just like to understand better
 the problem. Could you expand it in a scenario/use case to clarify the 
 risk?
 Nov- playing this back: is the concern that a user and a client might
 have the same identifier within an IDP? When using collision resistant IDs,
 as it is usually the case, that seems to be a remote possibility- did you
 stumble in such scenario in production?

 Thanks
 V.


 On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt <
 hans.zandb...@zmartzone.eu> wrote:

> I believe there are plenty of OAuth 2.0 only use cases out there...
> but nevertheless I agree with the potential confusion and thus security
> problems arising from that (though 

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

[George Fletcher]

I agree that this will break a lot of existing flows... especially those 
using any form of the client_credentials flow. In that sense I'm not 
completely on board yet :)


On 3/26/19 12:56 PM, Hans Zandbelt wrote:
great summary! this will hurt quite a few existing m2m deployments but 
I do like the rigidness of it all: it is very explicit, cannot 
misinterpreted and thus prevents failure (which is really what 
Dominick is after); I'm on board


Hans.

On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci 
> wrote:


thank you Steinar and everyone else for the comments on this!
To summarize the situation so far: Dominick, Steinar, Rob, David,
Nov, Bertrand recommend using sub only for users. Martin would
like to have the sub for app only flows as well. Hans is neutral.
That does sound like the sub as user has more consensus, tho
before changing it I'd wait for the people currently at IETF104 to
have more time to comment as well.
Clarification. If the goal is to be able to apply the logic "if
there's a sub, it's a user flow", we have to explicitly disallow
(MUST NOT) the use of sub when that's not the case. Are all OK
with it?

Dave, the suggestion of having explicit typing for app only vs
user only is interesting! For the purpose of putting together an
interoperable profile, tho, I would suggest we table it for v1 in
the interest of getting to something easy to adopt (hence with
small delta vs existing implementations) faster.

On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem mailto:stei...@udelt.no>> wrote:

Hi Vittorio, we (the national federation-gateway for the
health services in norway - "HelseID")  think his is a really
valuable initiative!
We also agree with Dominick concerning definition of the "sub"
claim.

Steinar

tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier
mailto:dba...@leastprivilege.com>>:

From an access token consumer (aka API) developer point of
view, I prefer this logic

"If sub is present - client acts on behalf of a user, if
not - not."

Anything more complicated has a potential of going wrong.


On 26. March 2019 at 01:34:53, Nov Matake
(mat...@gmail.com ) wrote:


Hi Vittorio,

Yeah, I’m concerning user & client ids collision.
I haven’t seen such implementations, but user-select
username as sub, or incremental integer as sub &
client_id will be easily collide.

If you can enforce collision resistant IDs between user &
client instances, it’ll works fine. I feel its overkill
though.

Sent from my iPhone

On Mar 26, 2019, at 8:51, Vittorio Bertocci
mailto:vitto...@auth0.com>> wrote:


Hey Nov, Dominick, Hans-
thanks for the comments. That was an area I was
expecting to cause more discussion, and I am glad we are
having this opportunity to clarify.
The current language in the draft traces the etymology
of sub to OpenID Connect core, hence Dominick
observation is on point. However in the description I
express something in line with 7519, which was in fact
my intent.

The idea was to provide an identifier of the calling
subject that is guaranteed to be present in all cases-
this would allow an SDK developer to use the same code
for things like lookups and membership checks regardless
of the nature of the caller (user in a delegated case,
app in app-only grants). The information to discriminate
between user and app callers is always available in the
token (say, the caller is a user if sub!=client_id,
where client_id is always guaranteed to be present as
well) hence there's no loss in expressive power, should
that difference be relevant for the resource server.

Dominick, Hans- I probably missed the security issue you
guys are thinking of in this case. Of course, if this
would introduce a risk I completely agree it should be
changed- I'd just like to understand better the problem.
Could you expand it in a scenario/use case to clarify
the risk?
Nov- playing this back: is the concern that a user and a
client might have the same identifier within an IDP?
When using collision resistant IDs, as it is usually the
case, that seems to be a remote possibility- did you
stumble in such scenario in production?

Thanks
V.


On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

[Vittorio Bertocci]

Thanks guys for the comment, sorry for the delay in addressing them.
I am not married to the claim types used in here, so if you think that
reusing the ones in the id_token can cause confusion we should expand on
the specific ways in which you think might go south.
However I think it's important that the information on say, whether the
current token was obtained using MFA or a specific authentication factor is
something that API developers can legitimately latch to when doing
authorization decisions. From the perspective of a developer modeling a
solution, whether functionality is delivered as a route in a postback based
web app (hence receiving an id_token or derived) or as an API consumed by a
native app, the business requirement gating access to that functionality
doesn't change. If the admin managing that resource establishes that access
should be performed only via MFA, the developer should be equipped to
enforce that regardless of the stack used to expose functionality (web app,
API).
Although it is true that triggering the desired behavior might be achieved
by the resource setting and contract with the AS, along the lines of what
David said, it's actually not uncommon for those policies to be assigned on
the resource AFTER the current session was established and/or the
corresponding AT was obtained and cached. Furthermore, the requirement
might be more granular than an AS policy can tolerate (an API might
requires MFA only for certain routes, hence hard to express in a static
policy) and triggered in form of challenges. So the situation in which you
have an AT with the right issuer, audience, etc but was obtained with a
policy now obsolete/unacceptable to the RP is strong. Requesting to support
revocation just for this seems overkill, especially given that the scenario
in which the same logical app is exposed as both web app and native
client+API, the code consuming those claims is already in place. It just
makes intuitive sense for developers.
In summary, one can take steps to push as much of the MFA requirements to
the AS settings for a particular request, but ultimately the desire of the
API developer to enforce that it actually happened is a requirement I
encountered often in practice. Anything providing extra context to refine
decisions about it (like auth_time, which might inform decisions about
whether to accept an MFA check occurred N minutes ago or refuse access).

I thought that reusing the existing names for the same concepts just made
sense (dev existing skills, existing codebases, etc etc) and especially in
the case in which the values are exactly the same, and the idea seemed to
receive good support during OSW. But I am completely open to change it of
course, especially for cases like the one identified by George.
WDYT?

On Wed, Apr 3, 2019 at 10:24 AM Brian Campbell  wrote:

> +1 to David's question here. I'd like to see justifying use cases (beyond
> just the fact that some people are already doing it) for auth_time, acr,
> and amr to be available in OAuth JWT access tokens. Those claims are
> defined for, and in the context of, an ID Token and I fear that codifying
> their use in an access token will lead to misuse and/or confusion.
>
> On Mon, Apr 1, 2019 at 1:03 PM David Waite 
> wrote:
>
>> Do we know if there is a justifying use case for auth_time, acr, and amr
>> to be available in OAuth JWT access tokens? These are meant to be messages
>> about the client, either directly (in the case of client credentials) or
>> about its delegated authorization of the user.
>>
>> Embedding attributes about the user (such as group membership and roles)
>> can be used for the resource to make finer-grained decisions than scopes,
>> but normally I would expect say acr limitations enforced by a resource to
>> instead be controlled by the AS requiring a higher quality authentication
>> to release certain scopes.
>>
>> Thats of course not to say extensions to OAuth such as OIDC can’t provide
>> these values, just that they might better be defined by those extensions..
>>
>> -DW
>>
>> On Apr 1, 2019, at 9:12 AM, George Fletcher <
>> gffletch=40aol@dmarc.ietf.org> wrote:
>>
>> Thanks for writing this up. One comment on auth_time...
>>
>>auth_time  OPTIONAL - as defined in section 2 of [OpenID.Core 
>> ].
>>   Important: as this claim represents the time at which the end user
>>   authenticated, its value will remain the same for all the JWT
>>   access tokens issued within that session.  For example: all the
>>   JWT access tokens obtained with a given refresh token will all
>>   have the same value of auth_time, corresponding to the instant in
>>   which the user first authenticated to obtain the refresh token.
>>
>>
>> During a current session a user can be challenged for additional
>> credentials or required to re-authenticate due to a number of different
>> reasons. For example, 

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

[Brian Campbell]

+1 to David's question here. I'd like to see justifying use cases (beyond
just the fact that some people are already doing it) for auth_time, acr,
and amr to be available in OAuth JWT access tokens. Those claims are
defined for, and in the context of, an ID Token and I fear that codifying
their use in an access token will lead to misuse and/or confusion.

On Mon, Apr 1, 2019 at 1:03 PM David Waite 
wrote:

> Do we know if there is a justifying use case for auth_time, acr, and amr
> to be available in OAuth JWT access tokens? These are meant to be messages
> about the client, either directly (in the case of client credentials) or
> about its delegated authorization of the user.
>
> Embedding attributes about the user (such as group membership and roles)
> can be used for the resource to make finer-grained decisions than scopes,
> but normally I would expect say acr limitations enforced by a resource to
> instead be controlled by the AS requiring a higher quality authentication
> to release certain scopes.
>
> Thats of course not to say extensions to OAuth such as OIDC can’t provide
> these values, just that they might better be defined by those extensions.
>
> -DW
>
> On Apr 1, 2019, at 9:12 AM, George Fletcher <
> gffletch=40aol@dmarc.ietf.org> wrote:
>
> Thanks for writing this up. One comment on auth_time...
>
>auth_time  OPTIONAL - as defined in section 2 of [OpenID.Core 
> ].
>   Important: as this claim represents the time at which the end user
>   authenticated, its value will remain the same for all the JWT
>   access tokens issued within that session.  For example: all the
>   JWT access tokens obtained with a given refresh token will all
>   have the same value of auth_time, corresponding to the instant in
>   which the user first authenticated to obtain the refresh token.
>
>
> During a current session a user can be challenged for additional
> credentials or required to re-authenticate due to a number of different
> reasons. For example, OIDC prompt=login or max_age=NNN. In this context,
> I'd assume that the auth_time value should be updated to the latest time at
> which the user authenticated.
>
> If we need a timestamp for when the "session" started, then there could be
> a session_start_time claim.
>
> Thanks,
> George
>
> On 3/24/19 7:29 PM, Vittorio Bertocci wrote:
>
> Dear all,
> I just submitted a draft describing a JWT profile for OAuth 2.0 access
> tokens. You can find it in
> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
> I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting
> remotely). I look forward for your comments!
>
> Here's just a bit of backstory, in case you are interested in how this doc
> came to be. The trajectory it followed is somewhat unusual.
>
>- Despite OAuth2 not requiring any specific format for ATs, through
>the years I have come across multiple proprietary solution using JWT for
>their access token. The intent and scenarios addressed by those solutions
>are mostly the same across vendors, but the syntax and interpretations in
>the implementations are different enough to prevent developers from reusing
>code and skills when moving from product to product.
>- I asked several individuals from key products and services to share
>with me concrete examples of their JWT access tokens (THANK YOU Dominick
>Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian
>(Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
>I studied and compared all those instances, identifying commonalities
>and differences.
>- I put together a presentation summarizing my findings and suggesting
>a rough interoperable profile (slides:
>
> https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx
>
> 
>) - got early feedback from Filip Skokan on it. Thx Filip!
>- The presentation was followed up by 1.5 hours of unconference
>discussion, which was incredibly valuable to get tight-loop feedback and
>incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov,
>Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there
>and contributed generously to the discussion. Thank you!!!
>Note: if you were at OSW2019, participated in the discussion and
>didn't get credited in the draft, my apologies: please send me a note and
>I'll make things right at the next update.
>- On my flight back I did my best to incorporate all the ideas and
>feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat,
>Hannes and above all Brian were all super helpful in negotiating the
>mysterious syntax of the RFC format and submission process.
>
> I was 

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

[George Fletcher]

Perfect! Thank you! A couple comments on version 01...

   POST /token HTTP/1.1
   Host: server.example.com
   Content-Type: application/x-www-form-urlencoded;charset=UTF-8
   DPoP-Binding: eyJhbGciOiJSU0ExXzUi ...

   grant_type=authorization_code
   =SplxlOBeZQQYbYS6WxSbIA
   _uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
   (remainder of JWK omitted for brevity)


I believe the "(remainder of JWK..." should be moved to the DPoP-Binding 
header...


Also, there is no discussion of the DPoP-Binding header outside of the 
token request, but I suspect that is the desired way to communicate the 
DPoP-Proof to the RS.


Possibly an example in the session for presenting the token to the RS 
would help.


Thanks,
George

On 4/3/19 11:39 AM, Daniel Fett wrote:

This is fixed in -01:

https://tools.ietf.org/html/draft-fett-oauth-dpop-01

-Daniel

Am 03.04.19 um 17:28 schrieb George Fletcher:

A quick question regarding...

o  "http_uri": The HTTP URI used for the request, without query and
   fragment parts (REQUIRED).

Is 'without' supposed to be 'with' ? The example shows the http_uri 
*with* the query parameters :)


On 3/28/19 6:17 AM, 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


___
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

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

[Daniel Fett]

This is fixed in -01:

https://tools.ietf.org/html/draft-fett-oauth-dpop-01

-Daniel

Am 03.04.19 um 17:28 schrieb George Fletcher:
> A quick question regarding...
>
>o  "http_uri": The HTTP URI used for the request, without query and
>   fragment parts (REQUIRED).
>
> Is 'without' supposed to be 'with' ? The example shows the http_uri
> *with* the query parameters :)
>
> On 3/28/19 6:17 AM, 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   
>>
>>
>> ___
>> 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

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

[George Fletcher]

From a security perspective, I think that using a UUID (or session 
cookie) which allows the SPA to retrieve the access_token is effectively 
the same as the confidential client directly returning the AT to the 
browser. Basically, it's the different between whether the browser has a 
copy of the access_token or not.


As to recommendations the AS might want to take, probably depends on a 
lot of factors. The factor that the browser has access to the 
access_token is just one of many affecting the overall risk to the 
Resource Server and the overall ecosystem. The risk of the browser 
having the access token is that there are more vectors for the token to 
be compromised and if the token is a bearer token then the risk is 
higher that the access token could be replayed by a malicious actor.


So, it's possible the AS might want to limit the ability of actions 
associated with those access tokens based on the risk of the actions 
enabled within the ecosystem by the RS.


I'm not sure there are definite recommendations that can be provided.

On 4/3/19 8:12 AM, Pedro Igor Silva wrote:

Hi,

I've seem some implementations where the token is not directly 
delivered to the browser by the backend, but some temporary UUID that 
later the SPA can exchange for an access token.


Do you think this is a good approach to the recommendation you are 
discussing?


In addition to that, could you clarify more what would be the 
limitations that ASes may wish to impose to these clients?


Regards.
Pedro Igor

On Tue, Apr 2, 2019 at 1:10 PM George Fletcher 
mailto:40aol@dmarc.ietf.org>> 
wrote:


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 mailto:gffle...@aol.com>> 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 mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[George Fletcher]

A quick question regarding...

   o  "http_uri": The HTTP URI used for the request, without query and
  fragment parts (REQUIRED).


Is 'without' supposed to be 'with' ? The example shows the http_uri 
*with* the query parameters :)


On 3/28/19 6:17 AM, 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


___
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

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

[Pedro Igor Silva]

Hi,

I've seem some implementations where the token is not directly delivered to
the browser by the backend, but some temporary UUID that later the SPA can
exchange for an access token.

Do you think this is a good approach to the recommendation you are
discussing?

In addition to that, could you clarify more what would be the limitations
that ASes may wish to impose to these clients?

Regards.
Pedro Igor

On Tue, Apr 2, 2019 at 1:10 PM George Fletcher  wrote:

> 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
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Ludwig Seitz]

On 02/04/2019 17:35, Brian Campbell wrote:
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.






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



My bad, figure 3 is not a token (although it looks like one) it's the 
token request (encapsulated in a JWS).


/Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51



smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth