As I am not a Kafka expert myself, but I will log an issue on our issues board regarding the need for an example tutorial. Based on what I have read, you would configure a messenger and use Kafka to communicate using FusionAuth. Or use Kafka as an integration point, and yes, webhooks would be involved.
I will discuss this with my colleagues and let you know if I discover anything further.
I will try to offer a few pointers, but as always, the juice is in the details. If you find yourself wanting more guidance, we do offer support plans to assist with implementation (not an upsell, just an option if needed per business requirements )
You could add Your Custom SSO as OpenID Connect Identity Provider. My thinking is that you could have FusionAuth issue an access token by visiting a login page and have your custom SSO accept that token, verify it, and then offer access to all the applications behind its "gate". In the picture from the documentation, replace pied piper with custom sso login button. Disclaimer: I may have to think more on this one to see if it best applies.
I will see if @dan, my colleague, has any other directional pointers to add or if I anything else pops to mind.
Many people use connectors when doing a staged migration of a system (documentation here) as you are. That would be a workflow to consider and educate yourself on. Specifically, there is a section in the documentation on Authentication that might be helpful to you.
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!
The user and registration may have a username field. The username field on the user is the one that can be used to login. In general you will want to use the Search API for those types of queries rather than directly accessing the database.
The reason is because the API is documented and stable, and the database is undocumented and may change.
I have a few questions for you to see if we can get to the bottom of this.
Is this an ongoing problem or has it recently surfaced? If recently surfaced, has anything changed which would slow your queries down? For instance, have you made any architecture changes? Was this user query much faster in the recent past?
What do queries from the Admin UI look like (are they performant?)?
Other things to evaluate include the size of your database and your architecture to make sure it's right-sized for your use case.
Finally, are you seeing anything in the error and event logs in FusionAuth (or in your server) that would indicate a larger problem?
Based on what I am seeing here, I don't believe this is an issue with FusionAuth, but if you discover something else, please let us know and we can file a bug report.
As you might have indicated, my instincts are telling me you had a popup rule blocking the required dialogs or that something in Privacy Badger does not like a combination of the "post" and something else about that URL. You could try disabling certain "privacy rules/settings" (not very familiar with Privacy Badger) to see if that alleviates your problem.