The react SDK UI doesn't support SSR.

However, session management can be done via SSR

Thanks!

Hey @rp where would I install the core if I’m using a managed db?

Managed db as in our managed service? Or something like AWS RDs?

Aws rds

Ah. You can run the core anywhere you’d like. Just give it the db connection details of your rds instance

Got it. Testing it on our dev server today. We are transitioning to rds this month

Alright!

Hello, what is the progress on the hasura integration?

Hi @User . Should be released in 1-2 weeks. We are done with the core, nodejs and golang changes. We need to work on docs and python SDK.

It required us to build support for open ID protocol and issue JWTs "inside" our sessions. These JWTs can be sent to hasura for auth within hasura.

Going to try to embed the React auth UIs into my Vue.js app... no clue if it's possible, but this thing exists: https://github.com/akxcv/vuera

If anyone has any experience with something similar, lmk!

It should be possible. Cause at the end of the day, it's all just based on web components underneath. One issue can be the final bundle size. It would contain the Vue framework & the react framework.

Amazing, going to give a try and will report back. Large bundle-size for version 1 is acceptable 🙂

fair!

Kudos to the Discord Server Admin!

Hi, I just found out about you guys, and I have a question. Why create supertoken instead of extending/forking keycloak?

Our architecture is fundamentally different than that of keycloack's: - For SuperTokens, the frontend doesn't talk to the Supertokens' Java core directly. It's always through the user's API layer. This means the public APIs that keycloak exposes need to be exposed via the user's API layer. So for SuperTokens, this is done via a backend SDK which the user needs to integrate with. The motivation for this is that API customisations can be done way more easily in comparison to Keycloak + we can provide end-to-end httpOnly session management out of the box. - We are modular in nature. For example, you can use SuperTokens just for session management and use another auth provider for login, or vice versa. Due to the modularity, we also don't force users to use protocols like OAuth when they don't need to. The motivation for this is simpler configs and docs. Again, extending Keycloak to do this would not be "natural".

Interesting, thank you!

Any specific reason to ask this? Or just curious?

Auth0 is having issues again. I was complaining to a friend about how we used to be trending towards making auth safer and easier with frameworks, but that as an industry we have shifted towards magical saas solutions that have pretty questionable trade offs. He's starting a company soon and asked me basic things about how auth works, which led me down the path of googling what sort of stuff is out there these days. I didn't know about keycloak until a couple weeks ago when I helped someone understand client certificates and build them for that, so I checked out their documentation a bit more and searched for alternatives and found you guys listed as an alternative.

Ah i see!

Interesting journey!

By questionable trade offs, I like the idea of trusting a third party to be highly available, to be super on top of security and to make best practices easy. When things go into feeling like lock in and rent seeking, that makes me really uncomfortable because it sets up for a long term relationship with an unhealthy power dynamic.

Yea! Makes sense. That problem is actually one of the big reasons for us creating SuperTokens in the first palce.

That's good to hear. Are you considering (or do you have) an opinionated way for people to store their concept of a user in their app? There are way too many places out there that think using email as a unique key is safe or reasonable.

We issue UUIDs per user that never change (for that user)

You can of course change a user's email too via our API. And each user's email is unique too.