FusionAuth + NextAuth refresh tokens

naughtly.keller

Hey @joshua thank you so much
I spent the weekend on it, and I have been successful. Honestly, FusionAuth has been a revelation. It's extremely powerful, and because of that I struggled a bit getting to know all the features. I apologize for my previous questions... They sound a bit silly now.

I was not yet aware of both the userinfo and introspect apis, so thanks again for letting me know about them. I like the userinfo api more, although introspect does return all the claims, including iat and exp. But before I get into it, please let me describe what I did. I'm no security expert, and I'd be happy if you could vet the process at a high level to make sure I'm not doing anything blatantly naive. Once I complete my implementation, I plan to write a tutorial about Next.js + FusionAuth + Hasura.

After signing in, I grab the accessToken prop and very manually run it through jsonwebtoken.verify using the public key stored on FusionAuth and hold a reference to that object. I then add to it Hasura's custom claims, and then sign this thing using a different RSA key, known by the Hasura server. When it's time to refresh the token I simply repeat the process: decoding the token, enhancing it with custom claims and signing it again. The resulting access token is stored in session and used to talk to the server.

The next step would be trying to implement the userinfo verification api you suggested instead of manually verifying the token.

I have a couple of questions now, which I hope you can answer:

You mentioned both iat and exp are reserved. I currently use them in my enhanced token to let hasura know when it's time to expire the token. As of my current understanding, every newly signed token would have at least a new iat set. What do you think I should use to set exp? Maybe the account.expires_in prop I get from FusionAuth?
The sign in process right now requires to call FusionAuth, then I would have to hit the userinfo endpoint and finally call hasura with an upsert operation in case of a new user. Wouldn't that be too chatty and slow? Would you suggest a different flow?
I'm currently using 2 different key pairs in this process: the FusionAuth's application RSA256 key for the login process, and an RSA512 key to sign/verify the final access token I send to hasura. Should I just use one key? Having FusionAuth manage keys would be great, but how can I use a key managed by FusionAuth to sign a token from the outside? I wasn't able to retrieve the private key or find an api for that.
Finally, is it possible to rotate keys automatically in FusionAuth like Firebase does for example?

I apologize for the long winded post and number of questions. Thank you very much for your time and kind support!

naughtly.keller

Hey @joshua ,
After complicating my life in a number of painful ways (please, check above) ️ which was still worthy for my learning journey, I ended up following all your advices FTW:

Using lambdas resulted in a much cleaner and faster implementation;
You can also get away without lambdas as well (look ma, no lambdas): all you need to do is map the available access token claims to those required by hasura;
You need no extra RSA keys and thanks to FusionAuth you don't even need to pass a public key to hasura: all you need is set the jwk_url parameter.

At the end of the day, the correct implementation was so smooth I doubt it will need a tutorial

joshua

@naughtly-keller!

Glad you got it worked out!

Let us know if there is anything that we can add to the documentation, etc to make it less painful for others .

As I was reviewing I did see that others have similar setups using adjacent tech stacks (Might be interesting to you):

Anyways, glad you got it working, and thanks for sharing the journey.

Thanks,
Josh

dan

@naughtly-keller Please share your application when it is live!

sander

@naughtly-keller Good one,

We are currently building an app on the same stack.

For user management we have written triggers and functions between hasura and fusionauth to keep the userdata in fusionauth up to date, we have also written all login, refresh and create user actions in hasura and functions.

If you want I can take you trough a tour...... and show you how we unified everything behind our Hasura gateway.

There is one issue we are currently working on before our stack is complete. The ability to use organizations. Maybe we can Collab on it and we will gladly share our code with you. @robotdan if @naughtly-keller wants to opensource the stack we are more than willing to contribute. We do have one issue in our implementation tho. And a little inspiration from your side would go a long way.

in our case all user management, syncing, login and other ops are executed by directly talking to our GQL endpoint( Hasura) this is all in working order. But we need to add organizations in the mix. We have an issue finding how we can leverage Fusionauth for this.

Ohh a preview test version of our app is available on https://thisisfashion.tv

dan

We'd love to highlight such an application or post if you wanted to share it..

As for organizations, I see a few options:

Groups/roles
Entities (you have to buy a license for this)
Model it in your own database and sync back and forth

It all depends on your use case, but each of these may work.

naughtly.keller

@dan I thought the difficulty was subjective, due to my inexperience with FusionAuth, but I can write down a tutorial and push a demo if you like

naughtly.keller

Hey @sander Can you be more precise about how you want to use organizations? Do you mean implementing some sort of multi-tenancy? I'd be happy to collaborate

sander

@dan
Ill give some more info on how we want to do it soon. as in a user story. whatever we come up with i woudl also like to incorporate in the blogpost / repos that we will share with @naughtly-keller.

Long story short would be.

How we solved users:
Create user request ====> graphql ===> azure function ( created user in FA, returns info, uses uuid and email to create user in our hasura DB users table. From the moment of creation of a user in DB, if in our DB something gets changed ( EG name usermane email etc, this request triggers a function to update and sync that change with Fusionauth.

For auth we include and X-hasura-user and role in the JWT. inside of hasura we pull this from the auth header and then a user is allowed to modify things in its own row and read information that goes with the role.

what we want with organizations:
This is fashion has a studio application much like Youtube studio to manage uploads to our platform. on this platform we want organizations to be able to manage their own content ( think brands, and their catwalks, films, shortfilms ) which then will be available for users on our platform to consume.

The prettiest solution would be if we can add an x-hasura-org with an organization UUID to the token. and include the role the user has in the organization as well. We would like handle organization details synchronization in the same way as we do with users at the moment. This way we could let a user switch organizations by changing their token. reason for this is we are planning on using microservices, and this way we can just pass the needed info in headers to those services.

within hasura there would be an organizations table very much like we have our users table now.

@naughtly-keller you can shoot me an email to setup a call and demo if you want sander@thisisfashion.tv

naughtly.keller

Hey @sander your issues seem to be related more with how Hasura's authorization system works than FusionAuth authentication. However, you can populate your JWT with the values you need. As @dan suggested, I would probably use Groups to model organizations, then it's easy to add the relative claims on the access token. So yes, you can populate your token with claims for both a set of roles and one or more organizations. Everything else should be in the authorization system domain, and considering you are using Hasura you can probably model those relationships in the database.

joshua

@naughtly-keller or @sander

Not sure if one of you were the creator of this?

https://next-auth.js.org/providers/fusionauth

or if not, at the very least I wanted to pass along the additional info that is now available

Thanks,
Josh