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

[Aaron Parecki <[e-mail]>]

In this type of deployment, as far as OAuth is concerned, isn't the backend
web server a confidential client? Is there even anything unique to this
situation as far as OAuth security goes?

I wouldn't have expected an Angular app that talks to its own server
backend that's managing OAuth credentials to fall under the umbrella of
this BCP.

----
Aaron Parecki
aaronparecki.com



On Sat, Dec 1, 2018 at 11:31 PM Torsten Lodderstedt <[e-mail]>
wrote:

> the UI is rendered in the frontend, UI control flow is in the frontend.
> just a different cut through the web app’s layering
>
> All Angular apps I have seen so far work that way. And it makes a lot of
> sense to me. The backend can aggregate and optimize access to the
> underlying services without the need to fully expose them.
>
> Am 02.12.2018 um 00:44 schrieb 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]>:
>
> 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]>:
>
> 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]> *On Behalf Of *Brian Campbell
> *Sent:* Friday, November 30, 2018 11:43 PM
> *To:* Torsten Lodderstedt <[e-mail]>
> *Cc:* oauth <[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]> wrote:
>
> > Am 15.11.2018 um 23:01 schrieb Brock Allen <[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]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing [e-mail]://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>