Re: [OAUTH-WG] JSON based access token requests for OAuth 2.1

2020-10-06 Thread Janak Amarasena
Hi Aaron, Let me clarify a bit. What I meant was the spec does not make it mandatory to use x-www-form-urlencoded I am stating this as I did not see any clause with the word "MUST" with regard to this. And also what I was asking was not to change using x-www-form-urlencoded to json. More like abou

Re: [OAUTH-WG] Implementation questions around refresh token rotation

2020-10-06 Thread Jeff Craig
My experience is more from the Client side of the equation on this problem, but I do have some thoughts. Our goal is to prevent cases where we lose the ability to Refresh a Token due to transient issues (which have run the gamut from network problems to bad software updates on the AS side). Our use

Re: [OAUTH-WG] Implementation questions around refresh token rotation

2020-10-06 Thread vittorio . bertocci=40auth0 . com
Hey Aaron, Auth0 does offer a configurable grace period, during which the “preceding” token can be reused. I am not 100% sure what we do in the exact scenario you described, and I will double check for you, but here’s my intuition. The operation redeem(RT_n) should result in AT, RT_n+1. Th

[OAUTH-WG] Implementation questions around refresh token rotation

2020-10-06 Thread Aaron Parecki
Hi all, I have a couple questions for those of you who have implemented refresh token rotation... Have you included the option of a grace period on refresh token use, allowing multiple uses within some time window? I'm wondering because a grace period where a refresh token may be used more than on

Re: [OAUTH-WG] JWT access tokens and the revocation endpoint

2020-10-06 Thread vittorio . bertocci=40auth0 . com
Hi Andrii, Thanks for the thoughtful comments! Here’s my 2 c. On the proposed language: given that the JWT AT profile is just providing more details on the content of an AT, making JWT ATs a proper subset of all ATs, readers should have no reason to believe that introspection or any other e

Re: [OAUTH-WG] JWT access tokens and the revocation endpoint

2020-10-06 Thread vittorio . bertocci=40auth0 . com
Thanks for the clarification! I agree, the scenarios you described would be improved by actually killing the ability of the app to access the resources, instead on relying on the client to discard the tokens without leaking them. That's why I am a big proponent of the online_access scope, tho I

Re: [OAUTH-WG] JWT access tokens and the revocation endpoint

2020-10-06 Thread vittorio . bertocci=40auth0 . com
Thanks for bringing the revocation topic up. In brief: * I agree on the comments that differentiate between userinfo and introspection- userinfo doesn’t really play a role in validation hence I’d keep it out of the JWT AT doc. * I agree that the introspection endpoint shouldn’t do

Re: [OAUTH-WG] JWT access tokens and the revocation endpoint

2020-10-06 Thread Jim Manico
Thanks for this message, Vittorio. > Say that I allow LinkedIn to tweet on my behalf. Once I have done that, it doesn’t matter whether I stay logged in their web app or otherwise. Ah, of course. That makes perfect sense. I should had been a lot more specific. I was commenting more on how many

Re: [OAUTH-WG] JWT access tokens and the revocation endpoint

2020-10-06 Thread Andrii Deinega
Vittorio and WG, Would it be possible to include something like the following to https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-10 In case the authorization server exposes the introspection, revocation, and OpenID Connect userinfo endpoints they MUST act in the same way as it happe

Re: [OAUTH-WG] JWT access tokens and the revocation endpoint

2020-10-06 Thread vittorio . bertocci=40auth0 . com
Hey Jim, regarding > Every logout event should trigger token revocation That isn’t necessarily the case. An access token represents the ability of a client to access a given resource; the fact that it requires an authentication transaction/session establishment to be issued to the client does not

Re: [OAUTH-WG] JSON based access token requests for OAuth 2.1

2020-10-06 Thread Aaron Parecki
The spec does clearly require form-encoded POST requests to the token endpoint, it's not just an implication. The requests made include simple key/value pairs so there's nothing really gained by making this a JSON post. Changing that at this point would be a drastic breaking change to pretty much a

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-16.txt

2020-10-06 Thread Daniel Fett
Hi all, the most important changes for this version are as follows: * New advice: For public clients, nonce is not sufficient to protect against authorization code injection. PKCE is now a MUST for public clients. * We have refined the guidance on using nonce for code injection pr

[OAUTH-WG] JSON based access token requests for OAuth 2.1

2020-10-06 Thread Janak Amarasena
Hi All, As per my understanding OAuth 2(RFC6749) doesn't mandate any specific media type to be used in the access token request. The spec implies application/x- www-form-urlencoded should be used. Since the media type application/json is very popular and widely used now, any thoughts on referencin

Re: [OAUTH-WG] JWT access tokens and the revocation endpoint

2020-10-06 Thread Thomas Broyer
On Sun, Oct 4, 2020 at 6:55 PM Nicolas Mora wrote: > Hello, > > Le 20-10-04 à 11 h 27, Thomas Broyer a écrit : > > > There might be some kind of pushed events between the AS and the RS > when > > a JWT AT is revoked, to allow the RS not to introspect a JWT AT at > all. > > Like this,