Feature: Support for RFC 7009 : Revoke Refresh Tokens

[robotdan]

Support for RFC 7009

Problem

FusionAuth already supports Refresh Token revocation, but it would be helpful to also support this standard revoke endpoint.
https://fusionauth.io/docs/v1/tech/apis/jwt#revoke-refresh-tokens

Solution

Support Refresh Token revoke as defined in RFC 7009 and publish the endpoint in the /.well-known/openid-configuration endpoint.

Alternatives/workarounds

Use https://fusionauth.io/docs/v1/tech/apis/jwt#revoke-refresh-tokens

Additional context

https://tools.ietf.org/html/rfc7009

How to vote

Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.

[scott2b]

This really turns out to be a deal-breaker for me. The use of JWTs as session keys alone are enough to give pause -- the problems with using JWT in this unintended way are fairly well documented, but the inability to revoke access tokens at all is really one too far. Coupled with a lot of quirkiness I am observing with session handling in general (inconsistencies in when cookies are set or revoked, lingering sessions, re-spawning of deleted users or revoked registrations) all adds up to either (1) I really don't know how to use FusionAuth's OAuth properly (which I will concede is a possibility) and the examples that are available don't really make usage clear (I'm mainly using the Flask example), or (2) FusionAuth's OAuth workflow simply must be accepted for high levels of potential security risk that it introduces (or at least the ease at which one can shoot oneself in the foot).

That all said: other than those issues (which seem to be fundamental on some level), FusionAuth is a really sharp looking and well made tool. An API-based workflow on the other hand is not prone to the same issues and caveats, and so unless one needs OAuth for some specific reason, may be a better approach. For my part, I am trying to decide whether to take this approach, but the lax security on OAuth based approaches sort of undermine my faith in the platform ... I am still deciding. It does seem that FusionAuth may not be the only auth platform that does it this way, and so again, there may simply be some fundamental things I just don't understand here, but for the moment, until I do understand those things, I am going to have to say, I cannot see using FusionAuth's OAuth based workflow in production.

fwiw, my explorations on this issue are documented in 2 repositories: First, in a branch of my fork of the Flask example here: https://github.com/scott2b/fusionauth-example-python-flask/tree/session_with_refresh. There are comments throughout the code that highlight issues described above. And secondly, because my ultimate intended usage is starlette based, I created this repository which has the remnants of an OAuth based workflow (and some of the same notes) but is finally settled into an API based approach: https://github.com/scott2b/fusionauth-example-python-starlette

[mooreds]

Hi @scott2b , thanks so much for your feedback. I'm glad that you took a long hard look at FusionAuth, and of course we appreciate that you liked it.

Just wanted to clarify a few things:

• you are a lot more likely to get good feedback if you post in the community forum than various GH issues lists. There are members of the community and team that that watch that forum.
• You don't have to use JWTs as the session mechanism with FusionAuth. You can go through the entire OAuth authorization code flow and then, if you get a valid JWT, set the value in the session, and use normal session management solutions. See step 9 of this diagram: https://fusionauth.io/learn/expert-advice/authentication/webapp/oauth-authorization-code-grant-sessions where the JWT is explicitly discarded.

[scott2b]

Thanks @mooreds. My primary goal here was to provide input on the RFC. All of the documentation and referencing is really just showing my work and not so much expecting feedback. I do have a forum account and have posted at least one thing there, and will try to use that space better.

Regarding non-use of tokens in the workflow you reference: step 10 ties the application's awareness of the user's information to the application's own session lifecycle which is not really acceptable for use cases I would consider. The user's information may be changed during that lifecycle, including auth controls resulting in a potential security hole, or an out-of-sync user experience at best.

And, as far as I can tell, this workflow does not address the more fundamental issue of the fact that the oauth workflow necessarily creates an open session in FusionAuth which is actually a cookie containing the issues JWTs, so as far as I can tell it is not really possible to fully "throw away" the tokens. But more to the point, that active session, in my explorations so far, seems to have a tendency to do things like respawn deleted users and/or registrations.

[mooreds]

Thanks @scott2b , appreciate it. Makes sense that you are providing feedback on whether FusionAuth should support this RFC. And thanks for upvoting it.

If you can provide repro steps around some of the unexpected behavior you see that you would consider a bug, please do file one. I haven't seen the behavior you mentioned and would love to understand it more with detailed repro steps if you have the time to provide them.

[scott2b]

Ok, dug in a bit, and I am revising my opinions based on new progress.

1. I have been unable to reproduce "user re-spawning". I don't know if this was a figment of my imagination, or if I just haven't nailed the right workflow in isolation. I will file an issue if I do ever reproduce this, but on the whole I am inclined to think this is not the problem I thought it was.
2. I have reproduced "registration re-spawning" but I have come to the conclusion that this is likely a feature and not a bug. It appears to be a side-effect of self-service registration enabling. I have documented my findings in a repository here. I will only file this as an "issue" if I am asked to either for historical documentation purposes, or if I have misinterpreted my findings.
3. I was inspired by @mooreds' comments and workflow pointer above and have developed an alternative workflow that does not use oauth tokens for ongoing session management. This workflow tracks the user ID in the session (in lieu of oauth tokens) and fetches the user directly from the API in the request cycle (rather than making an access and/or refresh request). So far I think this approach is much more sane, and is documented in my Starlette example here
4. This all adds up to a lot more sanity for me in my vision of how I might be using FusionAuth. I owe Dan for his feedback above that led me here, but I also stand by my thumbs-up for this feature and my assertion that JWTs are just bad for session-scoped access tokens. For more information about that, I recommend this blog post

[mooreds]

Wow, thanks fro the follow up, @scott2b! Self service registration does allow for anyone who logs in to an application to be automagically granted a registration. This is documented in the API: the application.registrationConfiguration.enabled field has this sentence: " If true, any user logging in to this application using hosted login pages will automatically have a registration created, if they are not already registered. " https://fusionauth.io/docs/v1/tech/apis/applications

But it could be clearer. No need to file an issue for point 2.

I agree that JWTs have tradeoffs when used to represent user sessions (like any other engineering choice). I have a blog post yet to write detailing those, but thanks for sharing what you found. I might link it here when I write it.

Thanks again for your persistence, and we can leave these comments here for anyone else who wants to read them.

[robotdan]

This is still a proposed standard. We should see if any other IdPs are implement this specific standard and if so, consider adding it.

You can always revoke refresh tokens using our APIs as well.

[mooreds]

Keycloak supports it: https://www.keycloak.org/keycloak-community/specifications/

Identity server supports it: https://docs.duendesoftware.com/identityserver/v5/overview/specs/

Ory.sh doesn't support it afaict.