Handle multiple Remix-Auth Strategies

[aydrian]

Currently it looks like the database is only set up to handle the Form Strategy. I saw in another post someone mention social logins which would need their own strategy. Have you given any thought to how you would handle multiple strategies with Remix-Auth, specifically with the database setup? There's the Auth.js Adapter approach which might be overly complicated. The password property on the User model is optional so maybe adding a strategy property will be enough.

[kentcdodds]

I still need to look into this. I'm definitely planning on supporting multiple in the starter. Probably GitHub. I'm thinking a strategy is the way to do it, but I can't say for sure until I do it.

[aydrian]

Ah. Got it. I noticed id is optional in that interface. Do we think every provider will have an id? That would affect which field to use in the unique constraint. I'm leaning toward using provider because every remix-auth provider has a name property that will likely be used for the provider field, right?

[kentcdodds]

I'm working on this a bit right now. It's been a while since I implemented OAuth 2 so forgive me, but shouldn't we be storing the refresh token and its expiration date (as well as the access token expiration) somewhere as well?

[sergiodxa]

Only if you plan to use the identity provider API.

If you only use (let's say Google or GitHub) to know who is the user (e.g. to store the email, name and an avatar) but you never fetch the Google or GitHub API then you don't need the access token, refresh token or expiration date of them, and for security it would be better to don't store them if you don't need them.

But if you do plan to use their API you will have to store them somewhere, then somehow refresh them. The refresh could work in some ways:

1. Try to use the access token, if expired refresh it, save the new token into the DB and try to use it again.
2. Run a background job that check the expired (or about to expire) tokens and refresh them, so your app can always use the access token supposing they will never be expired.
3. Combine both, so you have the token refreshed in background but your code can refresh and retry if it still fails.

I think for the majority of the apps, they only use OAuth to know who is the user, specially apps with more than one IdP option, but some apps do need to access the API, and in those cases they either have a single IdP option at login/signup or they need to request access later depending on what they plan to use.

[kentcdodds]

Ah, that makes plenty of sense. I suppose then that for the user identity case, it doesn't matter whether this option is checked:

But it's probably best to leave it checked so the access token can expire automatically.

Thanks for taking the time to explain that!

[sergiodxa]

Another thing to consider is how do you plan to use the token.

If you only use the token as the user interacts with the app (e.g. to fetch the repositories on GitHub) you could just keep the token in the session, read it from there and use it directly, once the token expires you could either refresh it or take the user to the login (access token expiration date and session expiration date could be the same in this scenario).

If you plan to use the token in the background (e.g. periodically fetch data from the API) you will need to store the tokens in the DB so you can use the access token and refresh it if needed.

[kentcdodds]

If anyone here wants to make an example, that would help a ton: https://github.com/epicweb-dev/epic-stack/blob/main/docs/examples.md

[kentcdodds]

I've added a new example to the docs. Here it is! https://github.com/kentcdodds/epic-github-auth

[cr101]

Thank you. Will this eventually make it into the core or will it stay as an example?

[kentcdodds]

Right now I think I'll keep it as an example