I also am in favor of not requiring "sender constraint" as a MUST.
SHOULD or RECOMMENDED is fine. Many websites are NOT Single-Page-Apps
and as such DPOP doesn't work for those environments. Converting all web
based environments to SPAs so not viable.
Thanks,
George
On 3/12/20 2:28 PM, Vittorio Bertocci wrote:
damnit, i hit enter too soon.
Hey guys,
thanks for putting this together.
I am concerned with the real world impact of imposing sender constraint |
rotation as a MUST on refresh tokens in every scenario.
Sender constraint isn't immediately actionable - we just had the discussion
for dPOP, hence I won't go in the details here.
Rotation isn't something that can be added without significant impact on
development and runtime experiences:
- on distributed scenarios, it introduces the need to serialize access
to shared caches
- network failures can lead to impact on experience- stranding clients
which fail to receive RTn+1 during RTn redemption in a limbo where user
interaction might become necessary, disrupting experience or functionality
for scenarios where the user isn't available to respond.
- remediations currently in the wild for this are either clunky (grace
periods) or downright cumbersome (waiting for the AT refreshed via RTn to
be used by the client to invalidate RTn, which locks RS and AS in a
transaction that is both expensive and itself subject to network failure)
I think it's fine to recommend using those mechanisms with a SHOULD, but
imposing those complexities to everyone in the core is asking too much IMO.
Thanks
V.
On Thu, Mar 12, 2020 at 11:24 AM Vittorio Bertocci <vitto...@auth0.com>
wrote:
Hey guys,
thanks for putting this together.
I am concerned with the real world impact of imposing sender constraint |
rotation as a MUST on refresh tokens in every scenario.
Sender constraint isn't immediately actionable - we just had the
discussion for dPOP, hence I won't go in the details here.
Rotation isn't something that can be added without significant impact on
development and runtime experiences:
- on distributed scenarios, it introduces the need to serialize access
to shared caches
- network failures can lead to impact on experience- stranding clients
which fail to receive RTn+1 during RTn redemption in a limbo where user
interaction might become necessary, disrupting experience or functionality
for scenarios where the user isn't available to respond.
-
On Wed, Mar 11, 2020 at 5:28 PM Aaron Parecki <aa...@parecki.com> wrote:
I'm happy to share that Dick and Torsten and I have published a first
draft of OAuth 2.1. We've taken the feedback from the discussions on
the list and incorporated that into the draft.
https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01
A summary of the differences between this draft and OAuth 2.0 can be
found in section 12, and I've copied them here below.
This draft consolidates the functionality in OAuth 2.0 (RFC6749),
OAuth 2.0 for Native Apps (RFC8252), Proof Key for Code Exchange
(RFC7636), OAuth 2.0 for Browser-Based Apps
(I-D.ietf-oauth-browser-based-apps), OAuth Security Best Current
Practice (I-D.ietf-oauth-security-topics), and Bearer Token Usage
(RFC6750).
Where a later draft updates or obsoletes functionality found in the
original [RFC6749], that functionality in this draft is updated with
the normative changes described in a later draft, or removed
entirely.
A non-normative list of changes from OAuth 2.0 is listed below:
* The authorization code grant is extended with the functionality
from PKCE ([RFC7636]) such that the only method of using the
authorization code grant according to this specification requires
the addition of the PKCE mechanism
* Redirect URIs must be compared using exact string matching as per
Section 4.1.3 of [I-D.ietf-oauth-security-topics]
* The Implicit grant ("response_type=token") is omitted from this
specification as per Section 2.1.2 of
[I-D.ietf-oauth-security-topics]
* The Resource Owner Password Credentials grant is omitted from this
specification as per Section 2.4 of
[I-D.ietf-oauth-security-topics]
* Bearer token usage omits the use of bearer tokens in the query
string of URIs as per Section 4.3.2 of
[I-D.ietf-oauth-security-topics]
* Refresh tokens must either be sender-constrained or one-time use
as per Section 4.12.2 of [I-D.ietf-oauth-security-topics]
https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-12
I'm excited for the direction this is taking, and it has been a
pleasure working with Dick and Torsten on this so far. My hope is that
this first draft can serve as a good starting point for our future
discussions!
----
Aaron Parecki
aaronparecki.com
@aaronpk
P.S. This notice was also posted at
https://aaronparecki.com/2020/03/11/14/oauth-2-1
_______________________________________________
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
