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
<tors...@lodderstedt.net <mailto:tors...@lodderstedt.net>>:
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
<hannes.tschofe...@arm.com <mailto:hannes.tschofe...@arm.com>>:
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 <oauth-boun...@ietf.org
<mailto:oauth-boun...@ietf.org>> *On Behalf Of *Brian Campbell
*Sent:* Friday, November 30, 2018 11:43 PM
*To:* Torsten Lodderstedt <tors...@lodderstedt.net
<mailto:tors...@lodderstedt.net>>
*Cc:* oauth <oauth@ietf.org <mailto:oauth@ietf.org>>
*Subject:* Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt
<tors...@lodderstedt.net <mailto:tors...@lodderstedt.net>> wrote:
> Am 15.11.2018 um 23:01 schrieb Brock Allen
<brockal...@gmail.com <mailto:brockal...@gmail.com>>:
>
> 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
OAuth@ietf.org <mailto: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
