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

[Hans Zandbelt <[e-mail]>]

On Mon, Dec 3, 2018 at 4:18 AM David Waite <[e-mail]>
wrote:

> If (as Hans proposed) there was a mechanism for javascript to get access
> tokens to interact with protected resources in lieu of the client, there
> could be BCP around managing that (which would likely also overlap with a
> genuine javascript-in-browser client), but unfortunately there aren’t
> technical specs to support that sort of architecture yet.
>

I agree with Aaron and David that this should be written up elsewhere and
hopefully be referred to from this BCP as it is relevant; anyone willing to
contribute and/or suggest where "elsewhere" is?

Hans.


> -DW
>
> On Dec 2, 2018, at 4:43 PM, Aaron Parecki <[e-mail]> wrote:
>
> 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
>>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
[e-mail]
ZmartZone IAM - www.zmartzone.eu