In this article (OAuth2 Implicit Grant and SPA) Vittorio wites, “Either way: I personally know of only two products supporting refresh token rotation as of today. Neither Microsoft, Google, nor Auth0 offer it at the moment.”
In this Auth0 documentation (Authorization Code Flow with Proof Key for Code Exchange (PKCE)) it talks Auth0’s ability to handle refresh tokens:
If you have Refresh Token Rotation enabled, a new Refresh Token is generated with each request and issued along with the Access Token. When a Refresh Token is exchanged, the previous Refresh Token is invalidated but information about the relationship is retained by the authorization server.
Should there be a note in that older article saying things have changed, or am I missing something? It’s quite confusing to read one thing and then read another from the same vendor (you really have to pay attention to dates).
Note that the Implicit Flow with Form Post documentation seems to indicate that Auth0 does implement Refresh Token Rotation for SPAs.
The OAuth 2.0 BCP states that you should not use the Implicit Flow to request Access Tokens from the Authorization Server. For this reason, we recommend that you use the Authorization Code Flow with PKCE if your single-page app (SPA) requires Access Tokens for Cross-Origin Resource Sharing (CORS) requests (along with Refresh Token Rotation if your SPA needs to maintain session). For a more detailed explanation, see our blog post: OAuth2 Implicit Grant and SPA: Everything you always wanted to know (but were afraid to ask).
There’s also a “Use rotating Refresh Tokens” section in this documentation:
https://auth0.com/docs/libraries/auth0-spa-js#use-rotating-refresh-tokens
Hey there, you are absolutely correct- the blog post you refer to was written before we added support for refresh token rotation- now Auth0 does support rotating refresh tokens, both in the service and in the SPA SDK. I’ll flag the post to the content team to see if they want to update the old post. Thanks!
2 Likes
Thanks @Vittorio. In that older article you also discuss token binding.
Is that still not available by most browsers?
If so, why did it die? I’m guessing it may have opened up doors to fingerprinting the browser (ie privacy issues)?
Still not available- it’s hard to state with certainty the reasons why it didn’t gain traction: everyone has an opinion, and I am no exception, but ultimately speculating won’t change the outcome 
The sender constraint torch has now passed to MTLS and dPOP, the latter officially adopted as draft by the oAuth working group. I am far more optimistic about dPOP success, as it doesn’t require many planets to align (the main flaw of the TB initiative, IMO) and is pretty easy to implement. If you are interested in sender constraint, I would recommend keeping an eye on dPOP evolution.
HTH, sorry for the terseness (typed on an iPhone)
2 Likes
Thanks for explaining all that @Vittorio!