Add ability to manage refresh tokens via API

[mooreds]

Add ability to manage refresh tokens via API

Problem

I want to be able to create and update refresh tokens for a user, not just retrieve them, via an API.

The particular use case for this is that I want to have a long lived token I can bind to a client using biometric protected storage. Then, when this token is released by someone with the correct biometric creds, I want to be able to mint an access token.

I could get a refresh token through the normal login process using the correct scope, but there's no other way to do so. I'd like to have more control over how I create these.

Solution

Add a create API method to the JWT API.

Alternatives/workarounds

Could have the long lived token be an access token instead of a refresh token.

Additional context

This came up on a kickoff call with a client.

Related issues

• https://github.com/FusionAuth/fusionauth-issues/issues/1515

Community guidelines

All issues filed in this repository must abide by the FusionAuth community guidelines.

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.

[robotdan]

This is interesting. I don't know that we have any plans to do something like this. You could use the JWT Vend API to get a JWT of any shape you wish.

I think this feature is basically asking for an API to log users in w/out them logging in. But that essentially means we are not the IdP.

Is this something we would want to support?

[mooreds]

This is a step beyond the login API and jwt vending API. We're still the IdP in the context of holding the "session" in the form of the refresh token, and that could be revoked normally.

This is similar to me to the vend JWT api in that, if you have an API key with permissions for this API, you can do whatever you want.

I think this feature is basically asking for an API to log users in w/out them logging in. But that essentially means we are not the IdP.

Isn't this exactly what the vend JWT API does too? If the end result of the login process is a JWT, then the ability to create an arbitrary JWT and have it signed by FusionAuth's private key is essentially the same as logging folks in without logging them in.

[icambron]

Here some context that might be helpful on why this is needed.

Fusion's APIs are oriented around the idea that the user flows through Fusion, either by directly interacting with Fusion's web pages, or through its workflow APIs. But that presumes that Fusion can support every random authentication mechanism out there, and thus has the necessary support to connect "user wants to log in" all the way to "user is logged in".

But this just isn't possible. Out in B2B SaaS land, there's all kinds of weird stuff. Authentication mechanism Fusion doesn't support, and often for very good reasons. Funny details in well-supported ones that don't map well onto Fusion's model. Legacy systems. It's a big weird world out here.

So you end up with the situation where if the app uses Fusion for some auth flows and some other weird thing for some other weird flow. But then these flows are forever separate. What I mean here is that the user who got into the app through Weird Legacy Auth Mechanism X doesn't get a Fusion refresh token because there's no way for Fusion to give them one, so they need some other way to refresh. Their logins can't be tracked in Fusion, etc. And more importantly, the application then has to have a "fusion mode" and an "other thing mode" because it will need separate code paths to deal with refreshing.

So being able to create refresh tokens via an API provides a bridge: the user logged in outside of Fusion, then that mechanism calls a Fusion API saying "look, you didn't let this user in but i did, and now you can keep track of them". In practice that means creating a refresh token and returning it to that other auth mechanism. Now the user is back on the same "track" as a non-legacy-logging-inning user and the rest of the system is none the wiser.