Note that this will enable you to set a global public key to verify the access token from the user. However, the access token's (not the same as an ID token) payload is not that of a standard JWT, so it also depends on what you want to do with the access token once it's signature is verified

ah it's not?

what does the payload look like?

would be great if it would contain the userId

what format is

<public key>;<private key>

pem? JWK?

The payload we have has the following: - `sessionHandle`: A constant ID per session. -

userId

- `refreshTokenHash1`: a reference to this token's refresh token - `parentRefreshTokenHash1`: a reference to the refresh token that was used to create this access token. - `userData`: Any JSON object that you wish to provide - `antiCsrfToken`: used to check if the incoming anti-csrf token is valid or not - `expiryTime`: in Milliseconds - `timeCreated`: in Milliseconds - `lmrt`: Used to check when the user had last manually authenticated

well that's totally fine

userData could contain roles or what not. Should be enough to do authorization based on the payload

> what format is ; pem? JWK? Yes .pem format, but without the

-----BEGIN PUBLIC KEY-----

and

-----END PUBLIC KEY-----

parts

alright

> userData could contain roles or what not. Should be enough to do authorization based on the payload Yes

i think i'll give it a try when i get the chance

cool! lmk if it works..

will do

It would be a lot better if the SuperTokens UI was framework agnostic. E.g if it was made using Stencil Web Components, this means it'd be plug and play for almost every framework. And then if the core functionality of recipes from the React library was extracted so it could be extended with custom http clients etc. I'm trying to extract it as an Angular library, which means I have to rewrite both

supertokens-website

and

supertokens-auth-react

Yes, thought so too... I feel it was designed this way to ensure specific issues surrounding session management around those frameworks are properly dealt with... A similar architecture you see with IaaS like Firebase

We specifically built our frontend for React, using react components since it allows us to provide a UI without the need for iframes, and to enable maximum customisation to users of reactJS.

Always easier to satisfy and grow around a small niche ✨

i don't think react is a small niche though..

Yeah, but you could do the exact same with web components and have it be used in every framework instead of being locked in with React. This enables max code reusability for integrations with all frameworks.

I'll defenitely have a look at stenciljs @User . Perhaps that is an excellent way ahead!

Then extract the actual core logic, and create platform specific providers, such as guards, interceptors etc for Angular, and the auth wrappers for React.

It's already using TSX, so not that big of a deal 😝

Would it be possible for users to define custom react components inside of stenciljs components?

Sure

Stencil supports slots aka children

I see.. that's quite cool!

Will def have a look in the coming few days! thanks a lot for the recommendation!

No worries! https://stenciljs.com/docs/react

You can automagically output libraries for every framework, it's quite cool.