Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[John Bradley <[e-mail]>]

How is that different from a regular server client with a web interface 
if the backed is doing the API calls to the RS?


On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote:
> I forgot to mention another (architectural) option: split an 
> application into frontend provided by JS in the browser and a backend, 
> which takes care of the business logic and handles tokens and API 
> access. Replay detection at the interface between SPA and backend can 
> utilize standard web techniques (see OWASP). The backend in turn can 
> use mTLS for sender constraining.
>
> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt 
> <[e-mail] <mailto:[e-mail]>>:
>
>> IMHO the best mechanism at hand currently to cope with token 
>> leakage/replay in SPAs is to use refresh tokens (rotating w/ replay 
>> detection) and issue short living and privilege restricted access tokens.
>>
>> Sender constrained access tokens in SPAs need adoption of token 
>> binding or alternative mechanism. mtls could potentially work in 
>> deployments with automated cert rollout but browser UX and interplay 
>> with fetch needs some work. We potentially must consider to warm up 
>> application level PoP mechanisms in conjunction with web crypto. 
>> Another path to be evaluated could be web auth.
>>
>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig 
>> <[e-mail] <mailto:[e-mail]>>:
>>
>>> I share the concern Brian has, which is also the conclusion I came 
>>> up with in my other email sent a few minutes ago.
>>>
>>> *From:*OAuth <[e-mail] 
>>> <mailto:[e-mail]>> *On Behalf Of *Brian Campbell
>>> *Sent:* Friday, November 30, 2018 11:43 PM
>>> *To:* Torsten Lodderstedt <[e-mail] 
>>> <mailto:[e-mail]>>
>>> *Cc:* oauth <[e-mail] <mailto:[e-mail]>>
>>> *Subject:* Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
>>>
>>> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt 
>>> <[e-mail] <mailto:[e-mail]>> wrote:
>>>
>>>     > Am 15.11.2018 um 23:01 schrieb Brock Allen
>>>     <[e-mail] <mailto:[e-mail]>>:
>>>     >
>>>     > So you mean at the resource server ensuring the token was
>>>     really issued to the client? Isn't that an inherent limitation
>>>     of all bearer tokens (modulo HTTP token binding, which is still
>>>     some time off)?
>>>
>>>     Sure. That’s why the Security BCP recommends use of TLS-based
>>>     methods for sender constraining access tokens
>>>     (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2).
>>>     Token Binding for OAuth
>>>     (https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08
>>>     <https://tools..ietf.org/html/draft-ietf-oauth-token-binding-08>)
>>>     as well as Mutual TLS for OAuth
>>>     (https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are the
>>>     options available.
>>>
>>> Unfortunately even when using the token endpoint, for SPA / 
>>> in-browser client applications, the potential mechanisms for 
>>> sender/key-constraining access tokens don't work very well or maybe 
>>> don't work at all. So I don't know that the recommendation is very 
>>> realistic.
>>>
>>>
>>> */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./*
>>>
>>> IMPORTANT NOTICE: The contents of this email and any attachments are 
>>> confidential and may also be privileged. If you are not the intended 
>>> recipient, please notify the sender immediately and do not disclose 
>>> the contents to any other person, use it for any purpose, or store 
>>> or copy the information in any medium. Thank you.
>> _______________________________________________
>> OAuth mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth