"Protect a route" question

[jacargentina]

@sergiodxa by going back to remix-auth after a long time, now I'm I doubt on this.

Protect a route example on the README: it gets the "cookie" and if it has a "user" on it, all is fine!! Is that right?
If that user Is now "deactivated" server side (for example) ?

Also my doubt is about: the authenticator is responsible for checking if given credentials are OK right?

I've found this strategy https://github.com/takagimeow/remix-auth-jwt which only checks the given Authorization header, but has no logic for generating the Bearer token. I don't know if I'm misunderstanding ... or takagimeow was, on how to implement this.

Again, thanks a lot!

[sergiodxa]

If that user Is now "deactivated" server side (for example) ?

This is a business logic concern, and outside the scope of Remix Auth, you can create a function that checks the cookie and then the DB to know if the user is deactivated.

Also my doubt is about: the authenticator is responsible for checking if given credentials are OK right?

No, the Authenticator only keeps tracks of the strategies, and lets you call them, that's it, strategies can do whatever they want but their main focus is to abstract the auth flow so you don't have to implement that, and focus only on the part that's unique for your app

I've found this strategy https://github.com/takagimeow/remix-auth-jwt which only checks the given Authorization header, but has no logic for generating the Bearer token. I don't know if I'm misunderstanding ... or takagimeow was, on how to implement this

I never used it, but from what I saw, it seems the strategy only focus on accessing the token from the header, decoding it and gives you the claims for your to actually check your DB.

[jacargentina]

But then: which is clearly “the scope of Remix auth” ? Sorry my insistance

or better: which are the task/s expected from a strategy?

[sergiodxa]

The idea is to abstract the authentication part, authentication is only to let you know who is the user.

The best example of this is the OAuth2 strategy, this strategy abstract the OAuth2 flow so you don't have to think about that, then it gives you the tokens it gets from the identity provider, those tokens identify the user.

Once you have the tokens what you do with that is up to you, you could store them in the session, in your DB, use them to fetch the user profile from the provider API, or maybe use them to find the user data on your DB and ignore the tokens.

Checking if the user is still enabled in the DB is part of the authorization flow, because you know who is the user (authentication), but you need to know what can the user do (authorization), and authorization is outside the scope of Remix Auth as that depends on your app business logic.

[jacargentina]

So then, as the form strategy does, JWT should also allow to generate the token I think, right?