It works correctly now 🙂 Thank you very much 🙂

Hi. I’m using SuperTokens in my project. Currently I have a NodeJS backend which connects to the SuperTokens auth core (I use session and emaipassword recipes). In addition I have a React app talking with the backend (with custom forms). Now I need to add another frontend react app (other domain). I want to have a group of new users who can only log in to the new app (they should not be able to log in to the current app). Have you got any suggestions how can I handle this situation with supertokens? I was thinking about creating user roles. How could I then add info about which app is the user logging in from? And also is it possible to reject the log in when the user does not have a certain role (without creating a custom endpoint)?

hey @User > I want to have a group of new users who can only log in to the new app (they should not be able to log in to the current app). How are you going to prevent these users from logging into the previous app? By detecting their email used and preventing them from signing up / logging in? > How could I then add info about which app is the user logging in from? You can associate a role to the user once they log in (based on their userID. See this page: https://supertokens.io/docs/emailpassword/common-customizations/user-roles/assigning-users-roles > And also is it possible to reject the log in when the user does not have a certain role Not as of now, but in a few days, we will make a new release that will let you do this very easily 🙂

Out of curiosity... Why do the tokens use custom claim names instead of the well-known/existing claim names? I'm thinking, in particular, of

sub

,

exp

, and

iat

(from RFC 7519) and

sid

(OIDC).

json
{
  "sessionHandle": "0d...",
  "userId": "97d...",
  "refreshTokenHash1": "550...",
  "userData": {},
  "expiryTime": 1623598349546,
  "timeCreated": 1623594749546,
  "lmrt": 1623594749546
}

@seniorquico cause the access token isn’t meant to be used like a typical JWT is meant to be used. A typical JWT is meant to let third party systems be able to verify the contents of the JWTs in a stateless manner. Whereas, our access tokens are strictly meant for session management between your frontend and backend only. No third party system involved.

As such, we merely borrow principles of a JWT (signing and stateless verification). You can think of them as signed payload instead of a typical JWT

An alternate to this would be to use a random string that points to the same payload (in a db). But this would require a db query for each API call.. so to prevent that latency, we used the stateless verification approach.

ok, i get the idea that they should be treated as opaque structures and delegated to SuperTokens for parsing/validation. however, i'm currently looking into using SuperTokens in a C# environment that doesn't yet have an official SDK, and, as such, i'm looking at needing to parse and validate the JWT. there are existing, well-tested libraries that parse and validate JWTs. however, i'm running into problems using them with SuperTokens out of the box. RFC 7519 calls for base64url encoding, but SuperTokens appears to be using the regular base64 encoding. and with respect to the claims, i'll need to recreate all of the validation routines due to the custom claim names. from the RFC: > they provide a starting point for a set of useful, interoperable claims i just find it curious that you decided to explicitly not use RFC 7519 with base64url encoding and the well-known, interoperable claim names.

It was a very conscious decision on our end to not follow the JWT spec here.. cause if we did, we thought it would be very easy for people to misuse the access token as a JWT and send it to third party services (like Hasura which uses JWTs for auth)...

fair enough. thanks for the info!

Wow, I looked for the same thing so thank you for the information. Do you use a generator to build your sdk? Because, it'll be very easy to build a C# or Rust (my case) to use Supertokens more quickly. For my MVP, I moved to fastapi because no sdk for rust. Have you an ETA about having full functionalities with sdk for fastapi? Regards

> Do you use a generator to build your sdk? i don't, and i don't see anything along those lines in the official ones. i'm just referring to the Node SDK. i've spent about a day reading through the code, and now i feel like i can port it relatively quickly-- hoping just a day or two with integration testing.

i'm specifically looking at using this in ASP.NET Core, and Microsoft already provides a modular authentication & authorization framework. it's looking fairly straightforward-- i simply need to implement a few, required abstractions. it looks like the bulk of my work is reverse engineering things like the above so that i can map it into the existing framework.

@seniorquico sorry, the question what's for @rp Ok, if it's a really hand made sdk, I understand and yes, it's what I'm looking also for Actix-Web (framework in Rust) but for the MVP, I can continue with fastapi. If I remember, Entity framework and another in C# are working well so yes, maybe it's not very hard to do all abstractions but it looks like crazy to don't respect the RFC, finally with the information from @rp , I understand why they're not respecting it.

@sycured for fastapi, it should be a few weeks.. we are building a generic python SDK and will add a fastapi wrapper to it.

@rp wow, you're working hard, thank you Will it be possible to use it with template in case of not using an spa? I'll have near 5-10 pages where spa will be very slow for browser side but I'll look to build it with wasm and library written in Rust

I’m not sure what you mean by template - do you mean server side rendering?

Yes

The old way to build website

Yea. We can work with that, as long as your API domain is the same (or subdomain) of your website domain

I’ll have a look at templates for fastapi soon. But I’m not too familiar with it.

It's the same with flask

I could describe the general approach we have for SSR + sessions and you could implement that using our SDKs (once they are available for python)

In fact, we may be writing a blog post about this very soon. So I’ll post that here once we have it

Ok thanks, I can wait the need sdk

Hi @User > I want to have a group of new users who can only log in to the new app (they should not be able to log in to the current app). > How are you going to prevent these users from logging into the previous app? By detecting their email used and preventing them from signing up / logging in? I was thinking about assigning roles to users, to check which app they can access. I do not use signup at all, users are created manually, so I can add roles easily. On login, the backend would need to know from which frontend app the log-in call comes (send some custom field along with the credentials from frontend?). Basing on it and the user role I could decide whether the user can log in and create a session (with a role assigned) or return some error.

@Orszi understood. Everything you mentioned should be possible with our new update (will be released in a few days). Post that, we can discuss how you can go about implementing the above (if the docs are not clear enough).

@rp thank you very much for your quick answer. I will check the new update and get back to you if have any question.

Just for an example of what I call "old way using templates", it's a basic but working example: https://eugeneyan.com/writing/how-to-set-up-html-app-with-fastapi-jinja-forms-templates/