Hi all,
Am 09.11.18 um 21:22 schrieb Brock Allen:
>
> Section "7.8. OAuth Implicit Grant Authorization Flow" does try to get
> into specifics, but many of the points seem confused (or at least
> confuse me) and/or the conclusion that code flow is the only approach
> seems misleading. For example:
Hmmm. But the Link-header is the generalized discovery method which is pretty
widely used outside of OAuth community with the added benefit of being able to
find things without linking to authentication.
From: OAuth On Behalf Of George Fletcher
Sent: Friday, November 09, 2018 12:12 AM
To: Dick
I have taken a stab at some text that will open the door for SAN-based
subject identity support. Some minor modifications in section 2.1, and
additional metadata parameters in section 2.1.2. Please find that text
below.
> I scanned through the SPIFFE docs but didn’t any mentioning of OAuth (just
> It still lacks the ability to issue sender constraint access tokens.
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)? Resource servers don't
Hi Brock,
> Am 15.11.2018 um 15:01 schrieb Brock Allen :
>
> > Helps to prevent leakage, not injection in the authorization response.
>
> So then wording and its motivation could get updated to correctly reflect
> that.
>
> >> "OAuth 2.0 provides no mechanism for a client to verify that an
Fwiw, this is something I thought about for Ozwillo but never ended up
implementing (though that still could happen): always issuing a refresh
token (vs. only when scope includes offline_access nowadays) but bind its
lifetime to the session when not offline_access. I would then revoke the
refresh
> Helps to prevent leakage, not injection in the authorization response.
So then wording and its motivation could get updated to correctly reflect that.
>> "OAuth 2.0 provides no mechanism for a client to verify that an access token
>> was issued to it, which could lead to misuse and possible
Hi,
here is the respective text proposal for section 2.1. (Note: we also refactored
the text in order to disentangle CSRF/replay and mix-up detection).
Clients MUST prevent CSRF and ensure that each authorization response is only
accepted once. One-time use CSRF tokens carried in the
