Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

[Dominick Baier]

No. But they are CSRF protected (either SameSite or anti-forgery) and
HttpOnly.

———
Dominick Baier

On 17. February 2021 at 21:08:37, Neil Madden (neil.mad...@forgerock.com)
wrote:

Do you eliminate the cookies too?

On 17 Feb 2021, at 19:50, Dominick Baier  wrote:


Well. Maybe it is at least worth while then to at least mention that you
could also take a slightly different approach and eliminate all tokens in
the browser - with the respective trade offs.

———
Dominick Baier

On 17. February 2021 at 20:46:42, Warren Parad (wpa...@rhosys.ch) wrote:

While someone will always say “but this doesn’t solve the XSS problem” -
> this is absolutely correct. But when there are no tokens in the browser -
> you can simply eliminate that part of the threat model ;)

The point was it doesn't eliminate anything, it just changes the
request/response data that is part of the attack. This doesn't increase
security, as a matter of fact, with regard to the RFC, we shouldn't talk
about security at all, since it has zero impact on it.

It is worth talking about that pattern as *one* possible solution to
maintaining sessions, but that's it.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress .


On Wed, Feb 17, 2021 at 8:43 PM Dominick Baier 
wrote:

> Yes - “no OAuth tokens in the browser” ;) They are all kept server-side
> and the BFF proxies the API calls if necessary. Also the RT management
> happens server-side and is transparent to the SPA.
>
> I see that in lots of industries - finance, health, cloud providers
>
> While someone will always say “but this doesn’t solve the XSS problem” -
> this is absolutely correct. But when there are no tokens in the browser -
> you can simply eliminate that part of the threat model ;)
>
> ———
> Dominick Baier
>
> On 17. February 2021 at 18:30:23, Vittorio Bertocci (
> vittorio.berto...@auth0.com) wrote:
>
> Thanks Dominick,
>
> It is indeed a very simple spec, but as you can see from the discussion so
> far, it doesn’t appear to be trivial- and there might be some
> considerations we consider obvious (eg scope escalation) that might not be
> super clear otherwise.
>
> In terms of the guidance, just to make sure I get the scope right- that
> means that also code+PKCE+rotating RTs in JS would not be acceptable for
> your customers?
>
>
>
> *From: *Dominick Baier 
> *Date: *Wednesday, February 17, 2021 at 00:27
> *To: *Brian Campbell , Torsten Lodderstedt <
> tors...@lodderstedt.net>
> *Cc: *Vittorio Bertocci , "oauth@ietf.org" <
> oauth@ietf.org>
> *Subject: *Re: [OAUTH-WG] Token Mediating and session Information Backend
> For Frontend (TMI BFF)
>
>
>
> Hey,
>
>
>
> Tbh - I have a bit of a hard time to see why this requires a spec, if that
> is all you are aiming at. Wouldn’t that be just an extension to the “OAuth
> for web apps BCP?”.
>
>
>
> All I can add here is - this approach would not work for any of our
> customer. Because their real motivation is to implement a more and more
> common security guideline these days - namely: “no JS-accessible tokens in
> the browser” - but this document doesn’t cover this.
>
>
>
> cheers
>
> ———
>
> Dominick Baier
>
>
>
> On 16. February 2021 at 22:01:37, Brian Campbell (
> bcampbell=40pingidentity@dmarc.ietf.org) wrote:
>
>
>
>
>
>
>
> On Mon, Feb 15, 2021 at 9:48 AM Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
> Thank you again for the explanation.
>
> I think your assumption about the overall flow should be described in the
> draft.
>
>
>
> We did attempt to capture the assumptions in the draft but clearly could
> have done a better job with it :)
>
>
>
>
> As I understand it now the core contribution of your proposal is to move
> refresh token management from frontend to backend. Is that correct?
>
>
>
>  Taking that a bit further - the idea is that the backend takes on the
> responsibilities of being a confidential client (client creds, token
> acquisition, token management/persistence, etc.) to the external AS(s). And
> TMI BFF describes a way for that backend to deliver access tokens to its
> own frontend.
>
>
> *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
>
> ___
> 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


ForgeRock values your Privacy 

Re: [OAUTH-WG] Authorization Header Encoding

[Brian Campbell]

AFAIK the character set for the "Bearer" scheme in RFC6750 is what it is to
align with the token68 part of "credentials = auth-scheme [ 1*SP ( token68
/ #auth-param ) ]" from https://tools.ietf.org/html/rfc7235#section-2.1
(the draft that would become RFC7235 is referenced by RFC6750 in
https://tools.ietf.org/html/rfc6750#section-2.1 where it says basically as
much).

Also it looks like https://github.com/httpwg/http-core/issues/733 was
closed with no action.

So I don't see what change would be made in OAuth 2.1 or elsewhere. Nor
does it seem like any change is needed or appropriate.

On Mon, Feb 15, 2021 at 4:34 AM Vladimir Dzhuvinov 
wrote:

> Hi Justin,
>
> Thanks for alerting us on this development.
>
> +1 for keeping the updated HTTP semantics unencumbered by the
> Authorization header formatting in RFC 6750.
>
> IMO revising the RFC 6750 to reflect that is too late now, as few people
> will notice. So updating the Bearer header definition in OAuth 2.1 seems
> like the most sensible move. I expect OAuth 2.0 implementers who maintain
> their software to pick up the 2.1 spec, sooner or later.
>
> Vladimir
>
>
> On 12/02/2021 00:01, Justin Richer wrote:
>
> The HTTP Working Group opened an issue for discussion in relation to the
> updated HTTP semantics specification. The core of the issue is the format
> of the “Authorization” header, which of course gets used by the “Bearer”
> scheme defined in RFC6750.
>
> https://github.com/httpwg/http-core/issues/733
>
> As it turns out, Bearer defines a more limited character set than is
> allowed by core HTTP, and doesn’t follow the HTTP guidelines and
> definitions for the Authorization header. There were a few observations on
> the call:
>
>  - The Bearer spec was limited because OAuth tokens were also allowed in
> HTTP URLs and form parameters (and therefore had to have a more limited
> character set)
>  - In practice people don’t actually restrict the values they put into
> this field; pretty much any implementation is just going to concatenate
> whatever access token value they get to the magic word “Bearer” and send it
>  - It’s not likely (or in my opinion proper) for the HTTP spec to change
> to address the oddities of RFC6750 and decisions that were made many years
> ago
>
> So the question is, what do we do about it? We could do a revision of 6750
> that reflects reality better, pretty much just changing the ABNF.
>
> Or, we could update the definition of the Bearer header in the upcoming
> OAuth 2.1 specification.
>
> Are there other options?
>
>  — Justin
>
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
> --
> Vladimir Dzhuvinov
>
> ___
> 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

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

[Brian Campbell]

Always appreciate (and often learn from) your insights, Neil. I'd like to
dig into the CSRF thing a bit more though to understand better and
hopefully do the right thing in the draft.

It seems to me that a GET at the bff-token endpoint is "safe" in that it's
effectively just a read. There could be a "cache miss" where the backend
attempts to use a refresh token it has to get a new access token from the
remote AS, which will be more resource intensive but doesn't fundamentally
alter the state of the backend so is still "safe". That in conjunction with
your pointing to Cross-Origin Read Blocking makes me think your concern
isn't so much about traditional CSRF used to take some malicious action but
rather about somehow (speculative side-channel attacks, problems with
javascript interpreters, other similar vectors that are somewhat beyond me)
accessing the data of the response to a forged cross site request. Correct
me if I'm wrong. I don't know if or how much the distinction matters in
terms of mitigation approach but I'm keen to better understand.

It sounds like your preference for only POST rests in an assumption that
the larger app will already have in place some CSRF defenses and by using
POST the bff-token endpoint will basically inherit said defenses. Or is
POST by itself good enough (the CORB writeup seems to suggest that the
context in which a POST could be made is more guarded against side channel
stuff)?  But perhaps then the draft should be more explicit about CSRF
defense? Saying it just has to be done. Or like even mandating a
non-standard header be in the request, "X-Neil-says-beware-CSRF: yuppers"
as a strawman. With such a header it could remain a GET. And I kinda like
GET because it is really a request for data.  Or perhaps the request should
be a POST with built-in CSRF protection by changing it to carry any
parameters as JSON in the body with "{}" for the case of no parameters
specified?  Or just make it a PUT and call it good? Not sure any of these
are good ideas but just trying to hash out the most appropriate thing to
do.

That got a little rambly, sorry. But hopefully it makes some sense.

On Sun, Feb 14, 2021 at 1:17 AM Neil Madden 
wrote:

>
> The combination of the bff-token endpoint recommending the use of GET
> requests together with the hint to use cookie-based authentication is
> likely going to punch a hole in most CSRF defenses, which assume that GETs
> are safe. The only thing preventing this being exploitable is Cross-Origin
> Read Blocking (
> https://chromium.googlesource.com/chromium/src/+/master/services/network/cross_origin_read_blocking_explainer.md)
> due to the JSON content-type. That makes me really nervous. We should at
> least mandate X-Content-Type-Options: nosniff on that response. I’d feel
> more comfortable if this was a POST request only.
>
> — Neil
>
>

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

[OAUTH-WG] Digest for DPoP

[Justin Richer]

Two different specifications (GNAP and FAPI signatures) have recently profiled 
DPoP to use its signature method to protect a different kind of protocol 
entirely. One thing these methods have in common is that they both define an 
additional field for holding a digest of the HTTP Message Body:

https://bitbucket.org/openid/fapi/src/master/Financial_API_Simple_HTTP_Message_Integrity_Protocol.md#markdown-header-521-htd-the-digest-of-the-http-request-or-response-body
 


https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-03.html#name-demonstration-of-proof-of-p
 


Both of these have the same semantics, and we’re changing the name in GNAP to 
align with the FAPI one. This begs the question: do we want to just define this 
field as an optional component in DPoP instead of having these profiles do it 
separately? It would save them from needing to align with each other, and 
anyone else from inventing it again.

Is it worth defining this in DPoP directly, or does that complicate the spec 
too much? I’ve previously raised a similar question on including a hash of the 
access token in the DPoP request to the RS.

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

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

[Neil Madden]

Do you eliminate the cookies too?

> On 17 Feb 2021, at 19:50, Dominick Baier  wrote:
> 
> 
> Well. Maybe it is at least worth while then to at least mention that you 
> could also take a slightly different approach and eliminate all tokens in the 
> browser - with the respective trade offs.
> 
> ———
> Dominick Baier
> 
>> On 17. February 2021 at 20:46:42, Warren Parad (wpa...@rhosys.ch) wrote:
>> 
>>> While someone will always say “but this doesn’t solve the XSS problem” - 
>>> this is absolutely correct. But when there are no tokens in the browser - 
>>> you can simply eliminate that part of the threat model ;)
>> The point was it doesn't eliminate anything, it just changes the 
>> request/response data that is part of the attack. This doesn't increase 
>> security, as a matter of fact, with regard to the RFC, we shouldn't talk 
>> about security at all, since it has zero impact on it.
>> 
>> It is worth talking about that pattern as one possible solution to 
>> maintaining sessions, but that's it.
>> 
>> 
>> Warren Parad
>> Founder, CTO
>> Secure your user data with IAM authorization as a service. Implement 
>> Authress.
>> 
>> 
>>> On Wed, Feb 17, 2021 at 8:43 PM Dominick Baier  
>>> wrote:
>>> Yes - “no OAuth tokens in the browser” ;) They are all kept server-side and 
>>> the BFF proxies the API calls if necessary. Also the RT management happens 
>>> server-side and is transparent to the SPA.
>>> 
>>> I see that in lots of industries - finance, health, cloud providers
>>> 
>>> While someone will always say “but this doesn’t solve the XSS problem” - 
>>> this is absolutely correct. But when there are no tokens in the browser - 
>>> you can simply eliminate that part of the threat model ;)
>>> 
>>> ———
>>> Dominick Baier
>>> 
 On 17. February 2021 at 18:30:23, Vittorio Bertocci 
 (vittorio.berto...@auth0.com) wrote:
 
 Thanks Dominick,
 
 It is indeed a very simple spec, but as you can see from the discussion so 
 far, it doesn’t appear to be trivial- and there might be some 
 considerations we consider obvious (eg scope escalation) that might not be 
 super clear otherwise.
 
 In terms of the guidance, just to make sure I get the scope right- that 
 means that also code+PKCE+rotating RTs in JS would not be acceptable for 
 your customers?
 
  
 
 From: Dominick Baier 
 Date: Wednesday, February 17, 2021 at 00:27
 To: Brian Campbell , Torsten Lodderstedt 
 
 Cc: Vittorio Bertocci , "oauth@ietf.org" 
 
 Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend 
 For Frontend (TMI BFF)
 
  
 
 Hey, 
 
  
 
 Tbh - I have a bit of a hard time to see why this requires a spec, if that 
 is all you are aiming at. Wouldn’t that be just an extension to the “OAuth 
 for web apps BCP?”.
 
  
 
 All I can add here is - this approach would not work for any of our 
 customer. Because their real motivation is to implement a more and more 
 common security guideline these days - namely: “no JS-accessible tokens in 
 the browser” - but this document doesn’t cover this.
 
  
 
 cheers 
 
 ———
 
 Dominick Baier
 
  
 
 On 16. February 2021 at 22:01:37, Brian Campbell 
 (bcampbell=40pingidentity@dmarc.ietf.org) wrote:
 
  
 
  
 
  
 
 On Mon, Feb 15, 2021 at 9:48 AM Torsten Lodderstedt 
  wrote:
 
 Thank you again for the explanation. 
 
 I think your assumption about the overall flow should be described in the 
 draft.
 
  
 
 We did attempt to capture the assumptions in the draft but clearly could 
 have done a better job with it :)
 
  
 
 
 As I understand it now the core contribution of your proposal is to move 
 refresh token management from frontend to backend. Is that correct? 
 
  
 
  Taking that a bit further - the idea is that the backend takes on the 
 responsibilities of being a confidential client (client creds, token 
 acquisition, token management/persistence, etc.) to the external AS(s). 
 And TMI BFF describes a way for that backend to deliver access tokens to 
 its own frontend. 
 
 
 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
 
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.or

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

[Warren Parad]

You mean all but the access token and authorization code, right?

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress .


On Wed, Feb 17, 2021 at 8:50 PM Dominick Baier 
wrote:

> Well. Maybe it is at least worth while then to at least mention that you
> could also take a slightly different approach and eliminate all tokens in
> the browser - with the respective trade offs.
>
> ———
> Dominick Baier
>
> On 17. February 2021 at 20:46:42, Warren Parad (wpa...@rhosys.ch) wrote:
>
> While someone will always say “but this doesn’t solve the XSS problem” -
>> this is absolutely correct. But when there are no tokens in the browser -
>> you can simply eliminate that part of the threat model ;)
>
> The point was it doesn't eliminate anything, it just changes the
> request/response data that is part of the attack. This doesn't increase
> security, as a matter of fact, with regard to the RFC, we shouldn't talk
> about security at all, since it has zero impact on it.
>
> It is worth talking about that pattern as *one* possible solution to
> maintaining sessions, but that's it.
>
> Warren Parad
>
> Founder, CTO
> Secure your user data with IAM authorization as a service. Implement
> Authress .
>
>
> On Wed, Feb 17, 2021 at 8:43 PM Dominick Baier 
> wrote:
>
>> Yes - “no OAuth tokens in the browser” ;) They are all kept server-side
>> and the BFF proxies the API calls if necessary. Also the RT management
>> happens server-side and is transparent to the SPA.
>>
>> I see that in lots of industries - finance, health, cloud providers
>>
>> While someone will always say “but this doesn’t solve the XSS problem” -
>> this is absolutely correct. But when there are no tokens in the browser -
>> you can simply eliminate that part of the threat model ;)
>>
>> ———
>> Dominick Baier
>>
>> On 17. February 2021 at 18:30:23, Vittorio Bertocci (
>> vittorio.berto...@auth0.com) wrote:
>>
>> Thanks Dominick,
>>
>> It is indeed a very simple spec, but as you can see from the discussion
>> so far, it doesn’t appear to be trivial- and there might be some
>> considerations we consider obvious (eg scope escalation) that might not be
>> super clear otherwise.
>>
>> In terms of the guidance, just to make sure I get the scope right- that
>> means that also code+PKCE+rotating RTs in JS would not be acceptable for
>> your customers?
>>
>>
>>
>> *From: *Dominick Baier 
>> *Date: *Wednesday, February 17, 2021 at 00:27
>> *To: *Brian Campbell , Torsten Lodderstedt <
>> tors...@lodderstedt.net>
>> *Cc: *Vittorio Bertocci , "oauth@ietf.org" <
>> oauth@ietf.org>
>> *Subject: *Re: [OAUTH-WG] Token Mediating and session Information
>> Backend For Frontend (TMI BFF)
>>
>>
>>
>> Hey,
>>
>>
>>
>> Tbh - I have a bit of a hard time to see why this requires a spec, if
>> that is all you are aiming at. Wouldn’t that be just an extension to the
>> “OAuth for web apps BCP?”.
>>
>>
>>
>> All I can add here is - this approach would not work for any of our
>> customer. Because their real motivation is to implement a more and more
>> common security guideline these days - namely: “no JS-accessible tokens in
>> the browser” - but this document doesn’t cover this.
>>
>>
>>
>> cheers
>>
>> ———
>>
>> Dominick Baier
>>
>>
>>
>> On 16. February 2021 at 22:01:37, Brian Campbell (
>> bcampbell=40pingidentity@dmarc.ietf.org) wrote:
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Feb 15, 2021 at 9:48 AM Torsten Lodderstedt <
>> tors...@lodderstedt.net> wrote:
>>
>> Thank you again for the explanation.
>>
>> I think your assumption about the overall flow should be described in the
>> draft.
>>
>>
>>
>> We did attempt to capture the assumptions in the draft but clearly could
>> have done a better job with it :)
>>
>>
>>
>>
>> As I understand it now the core contribution of your proposal is to move
>> refresh token management from frontend to backend. Is that correct?
>>
>>
>>
>>  Taking that a bit further - the idea is that the backend takes on the
>> responsibilities of being a confidential client (client creds, token
>> acquisition, token management/persistence, etc.) to the external AS(s). And
>> TMI BFF describes a way for that backend to deliver access tokens to its
>> own frontend.
>>
>>
>> *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
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
__

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

[Dominick Baier]

Well. Maybe it is at least worth while then to at least mention that you
could also take a slightly different approach and eliminate all tokens in
the browser - with the respective trade offs.

———
Dominick Baier

On 17. February 2021 at 20:46:42, Warren Parad (wpa...@rhosys.ch) wrote:

While someone will always say “but this doesn’t solve the XSS problem” -
> this is absolutely correct. But when there are no tokens in the browser -
> you can simply eliminate that part of the threat model ;)

The point was it doesn't eliminate anything, it just changes the
request/response data that is part of the attack. This doesn't increase
security, as a matter of fact, with regard to the RFC, we shouldn't talk
about security at all, since it has zero impact on it.

It is worth talking about that pattern as *one* possible solution to
maintaining sessions, but that's it.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress .


On Wed, Feb 17, 2021 at 8:43 PM Dominick Baier 
wrote:

> Yes - “no OAuth tokens in the browser” ;) They are all kept server-side
> and the BFF proxies the API calls if necessary. Also the RT management
> happens server-side and is transparent to the SPA.
>
> I see that in lots of industries - finance, health, cloud providers
>
> While someone will always say “but this doesn’t solve the XSS problem” -
> this is absolutely correct. But when there are no tokens in the browser -
> you can simply eliminate that part of the threat model ;)
>
> ———
> Dominick Baier
>
> On 17. February 2021 at 18:30:23, Vittorio Bertocci (
> vittorio.berto...@auth0.com) wrote:
>
> Thanks Dominick,
>
> It is indeed a very simple spec, but as you can see from the discussion so
> far, it doesn’t appear to be trivial- and there might be some
> considerations we consider obvious (eg scope escalation) that might not be
> super clear otherwise.
>
> In terms of the guidance, just to make sure I get the scope right- that
> means that also code+PKCE+rotating RTs in JS would not be acceptable for
> your customers?
>
>
>
> *From: *Dominick Baier 
> *Date: *Wednesday, February 17, 2021 at 00:27
> *To: *Brian Campbell , Torsten Lodderstedt <
> tors...@lodderstedt.net>
> *Cc: *Vittorio Bertocci , "oauth@ietf.org" <
> oauth@ietf.org>
> *Subject: *Re: [OAUTH-WG] Token Mediating and session Information Backend
> For Frontend (TMI BFF)
>
>
>
> Hey,
>
>
>
> Tbh - I have a bit of a hard time to see why this requires a spec, if that
> is all you are aiming at. Wouldn’t that be just an extension to the “OAuth
> for web apps BCP?”.
>
>
>
> All I can add here is - this approach would not work for any of our
> customer. Because their real motivation is to implement a more and more
> common security guideline these days - namely: “no JS-accessible tokens in
> the browser” - but this document doesn’t cover this.
>
>
>
> cheers
>
> ———
>
> Dominick Baier
>
>
>
> On 16. February 2021 at 22:01:37, Brian Campbell (
> bcampbell=40pingidentity@dmarc.ietf.org) wrote:
>
>
>
>
>
>
>
> On Mon, Feb 15, 2021 at 9:48 AM Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
> Thank you again for the explanation.
>
> I think your assumption about the overall flow should be described in the
> draft.
>
>
>
> We did attempt to capture the assumptions in the draft but clearly could
> have done a better job with it :)
>
>
>
>
> As I understand it now the core contribution of your proposal is to move
> refresh token management from frontend to backend. Is that correct?
>
>
>
>  Taking that a bit further - the idea is that the backend takes on the
> responsibilities of being a confidential client (client creds, token
> acquisition, token management/persistence, etc.) to the external AS(s). And
> TMI BFF describes a way for that backend to deliver access tokens to its
> own frontend.
>
>
> *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
>
> ___
> 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] Token Mediating and session Information Backend For Frontend (TMI BFF)

[Warren Parad]

>
> While someone will always say “but this doesn’t solve the XSS problem” -
> this is absolutely correct. But when there are no tokens in the browser -
> you can simply eliminate that part of the threat model ;)

The point was it doesn't eliminate anything, it just changes the
request/response data that is part of the attack. This doesn't increase
security, as a matter of fact, with regard to the RFC, we shouldn't talk
about security at all, since it has zero impact on it.

It is worth talking about that pattern as *one* possible solution to
maintaining sessions, but that's it.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress .


On Wed, Feb 17, 2021 at 8:43 PM Dominick Baier 
wrote:

> Yes - “no OAuth tokens in the browser” ;) They are all kept server-side
> and the BFF proxies the API calls if necessary. Also the RT management
> happens server-side and is transparent to the SPA.
>
> I see that in lots of industries - finance, health, cloud providers
>
> While someone will always say “but this doesn’t solve the XSS problem” -
> this is absolutely correct. But when there are no tokens in the browser -
> you can simply eliminate that part of the threat model ;)
>
> ———
> Dominick Baier
>
> On 17. February 2021 at 18:30:23, Vittorio Bertocci (
> vittorio.berto...@auth0.com) wrote:
>
> Thanks Dominick,
>
> It is indeed a very simple spec, but as you can see from the discussion so
> far, it doesn’t appear to be trivial- and there might be some
> considerations we consider obvious (eg scope escalation) that might not be
> super clear otherwise.
>
> In terms of the guidance, just to make sure I get the scope right- that
> means that also code+PKCE+rotating RTs in JS would not be acceptable for
> your customers?
>
>
>
> *From: *Dominick Baier 
> *Date: *Wednesday, February 17, 2021 at 00:27
> *To: *Brian Campbell , Torsten Lodderstedt <
> tors...@lodderstedt.net>
> *Cc: *Vittorio Bertocci , "oauth@ietf.org" <
> oauth@ietf.org>
> *Subject: *Re: [OAUTH-WG] Token Mediating and session Information Backend
> For Frontend (TMI BFF)
>
>
>
> Hey,
>
>
>
> Tbh - I have a bit of a hard time to see why this requires a spec, if that
> is all you are aiming at. Wouldn’t that be just an extension to the “OAuth
> for web apps BCP?”.
>
>
>
> All I can add here is - this approach would not work for any of our
> customer. Because their real motivation is to implement a more and more
> common security guideline these days - namely: “no JS-accessible tokens in
> the browser” - but this document doesn’t cover this.
>
>
>
> cheers
>
> ———
>
> Dominick Baier
>
>
>
> On 16. February 2021 at 22:01:37, Brian Campbell (
> bcampbell=40pingidentity@dmarc.ietf.org) wrote:
>
>
>
>
>
>
>
> On Mon, Feb 15, 2021 at 9:48 AM Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
> Thank you again for the explanation.
>
> I think your assumption about the overall flow should be described in the
> draft.
>
>
>
> We did attempt to capture the assumptions in the draft but clearly could
> have done a better job with it :)
>
>
>
>
> As I understand it now the core contribution of your proposal is to move
> refresh token management from frontend to backend. Is that correct?
>
>
>
>  Taking that a bit further - the idea is that the backend takes on the
> responsibilities of being a confidential client (client creds, token
> acquisition, token management/persistence, etc.) to the external AS(s). And
> TMI BFF describes a way for that backend to deliver access tokens to its
> own frontend.
>
>
> *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
>
> ___
> 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] Token Mediating and session Information Backend For Frontend (TMI BFF)

[Dominick Baier]

Yes - “no OAuth tokens in the browser” ;) They are all kept server-side and
the BFF proxies the API calls if necessary. Also the RT management happens
server-side and is transparent to the SPA.

I see that in lots of industries - finance, health, cloud providers

While someone will always say “but this doesn’t solve the XSS problem” -
this is absolutely correct. But when there are no tokens in the browser -
you can simply eliminate that part of the threat model ;)

———
Dominick Baier

On 17. February 2021 at 18:30:23, Vittorio Bertocci (
vittorio.berto...@auth0.com) wrote:

Thanks Dominick,

It is indeed a very simple spec, but as you can see from the discussion so
far, it doesn’t appear to be trivial- and there might be some
considerations we consider obvious (eg scope escalation) that might not be
super clear otherwise.

In terms of the guidance, just to make sure I get the scope right- that
means that also code+PKCE+rotating RTs in JS would not be acceptable for
your customers?



*From: *Dominick Baier 
*Date: *Wednesday, February 17, 2021 at 00:27
*To: *Brian Campbell , Torsten Lodderstedt <
tors...@lodderstedt.net>
*Cc: *Vittorio Bertocci , "oauth@ietf.org" <
oauth@ietf.org>
*Subject: *Re: [OAUTH-WG] Token Mediating and session Information Backend
For Frontend (TMI BFF)



Hey,



Tbh - I have a bit of a hard time to see why this requires a spec, if that
is all you are aiming at. Wouldn’t that be just an extension to the “OAuth
for web apps BCP?”.



All I can add here is - this approach would not work for any of our
customer. Because their real motivation is to implement a more and more
common security guideline these days - namely: “no JS-accessible tokens in
the browser” - but this document doesn’t cover this.



cheers

———

Dominick Baier



On 16. February 2021 at 22:01:37, Brian Campbell (
bcampbell=40pingidentity@dmarc.ietf.org) wrote:







On Mon, Feb 15, 2021 at 9:48 AM Torsten Lodderstedt 
wrote:

Thank you again for the explanation.

I think your assumption about the overall flow should be described in the
draft.



We did attempt to capture the assumptions in the draft but clearly could
have done a better job with it :)




As I understand it now the core contribution of your proposal is to move
refresh token management from frontend to backend. Is that correct?



 Taking that a bit further - the idea is that the backend takes on the
responsibilities of being a confidential client (client creds, token
acquisition, token management/persistence, etc.) to the external AS(s). And
TMI BFF describes a way for that backend to deliver access tokens to its
own frontend.


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

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

[Hans Zandbelt]

Thanks Vittorio and Brian for starting this work: I have deployed this
pattern in the field on a number occasions, at security and tech savvy
organizations, on their request.
I'd describe it as a regular OAuth 2.0 web client with the addition of a
well known endpoint meant for in-browser (counterpart) clients.

Enterprise security architects seem to prefer this approach because of the
confidential client involved and the ability to outsource a perceived
cumbersome and security sensitive task to a backend
infrastructure component under direct control of the organization rather
than the end user. Even if there's no proven security advantage by letter
of the OAuth 2 spec, it may still be a preferred way of deployment for some
organizations because of the way they want to structure security sensitive
software, the way they deal with software development, and the way they
deal with application and infrastructure management.

I very much agree with all of the arguments Vittorio brought up before and
I really don't see any reason to reject this approach. It is very useful to
list the considerations about this architectural pattern and to give
guidance about when it can be used and when to avoid it, regardless of the
complexity or length of such a spec.

Hans.

On Tue, Feb 16, 2021 at 10:02 PM Brian Campbell  wrote:

>
>
>
> On Mon, Feb 15, 2021 at 9:48 AM Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
>> Thank you again for the explanation.
>>
>> I think your assumption about the overall flow should be described in the
>> draft.
>>
>
> We did attempt to capture the assumptions in the draft but clearly could
> have done a better job with it :)
>
>
>>
>> As I understand it now the core contribution of your proposal is to move
>> refresh token management from frontend to backend. Is that correct?
>>
>
>  Taking that a bit further - the idea is that the backend takes on the
> responsibilities of being a confidential client (client creds, token
> acquisition, token management/persistence, etc.) to the external AS(s). And
> TMI BFF describes a way for that backend to deliver access tokens to its
> own frontend.
>
> *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
>


-- 
hans.zandb...@zmartzone.eu
ZmartZone IAM - www.zmartzone.eu
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

[Vittorio Bertocci]

Thanks Dominick,
It is indeed a very simple spec, but as you can see from the discussion so far, 
it doesn’t appear to be trivial- and there might be some considerations we 
consider obvious (eg scope escalation) that might not be super clear otherwise.
In terms of the guidance, just to make sure I get the scope right- that means 
that also code+PKCE+rotating RTs in JS would not be acceptable for your 
customers?

From: Dominick Baier 
Date: Wednesday, February 17, 2021 at 00:27
To: Brian Campbell , Torsten Lodderstedt 

Cc: Vittorio Bertocci , "oauth@ietf.org" 

Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For 
Frontend (TMI BFF)

Hey,

Tbh - I have a bit of a hard time to see why this requires a spec, if that is 
all you are aiming at. Wouldn’t that be just an extension to the “OAuth for web 
apps BCP?”.

All I can add here is - this approach would not work for any of our customer. 
Because their real motivation is to implement a more and more common security 
guideline these days - namely: “no JS-accessible tokens in the browser” - but 
this document doesn’t cover this.

cheers
———
Dominick Baier


On 16. February 2021 at 22:01:37, Brian Campbell 
(bcampbell=40pingidentity@dmarc.ietf.org)
 wrote:



On Mon, Feb 15, 2021 at 9:48 AM Torsten Lodderstedt 
mailto:tors...@lodderstedt.net>> wrote:
Thank you again for the explanation.

I think your assumption about the overall flow should be described in the draft.

We did attempt to capture the assumptions in the draft but clearly could have 
done a better job with it :)


As I understand it now the core contribution of your proposal is to move 
refresh token management from frontend to backend. Is that correct?

 Taking that a bit further - the idea is that the backend takes on the 
responsibilities of being a confidential client (client creds, token 
acquisition, token management/persistence, etc.) to the external AS(s). And TMI 
BFF describes a way for that backend to deliver access tokens to its own 
frontend.

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

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

[Dominick Baier]

Hey,

Tbh - I have a bit of a hard time to see why this requires a spec, if that
is all you are aiming at. Wouldn’t that be just an extension to the “OAuth
for web apps BCP?”.

All I can add here is - this approach would not work for any of our
customer. Because their real motivation is to implement a more and more
common security guideline these days - namely: “no JS-accessible tokens in
the browser” - but this document doesn’t cover this.

cheers
———
Dominick Baier

On 16. February 2021 at 22:01:37, Brian Campbell (
bcampbell=40pingidentity@dmarc.ietf.org) wrote:




On Mon, Feb 15, 2021 at 9:48 AM Torsten Lodderstedt 
wrote:

> Thank you again for the explanation.
>
> I think your assumption about the overall flow should be described in the
> draft.
>

We did attempt to capture the assumptions in the draft but clearly could
have done a better job with it :)


>
> As I understand it now the core contribution of your proposal is to move
> refresh token management from frontend to backend. Is that correct?
>

 Taking that a bit further - the idea is that the backend takes on the
responsibilities of being a confidential client (client creds, token
acquisition, token management/persistence, etc.) to the external AS(s). And
TMI BFF describes a way for that backend to deliver access tokens to its
own frontend.

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