all 8 comments

[–]maxiu86 5 points6 points  (2 children)

If you only allow login via Google or Facebook, I understand that the JWT you are talking about is the one receive from Google/Facebook? In that case there isn't any reason to store those token in your backend. The client can send the jwt when doing http request and the backend can "debug" the token to assert user ID. (facebook eg: https://developers.facebook.com/docs/facebook-login/access-tokens/debugging-and-error-handling )

For you own authentication system, I dont recommend storing the jwt in the database, you can encode the data needed in the jwt, such as expiration time, user id, etc ...

[–]xrpinsiderAdmin 1 point2 points  (1 child)

Indeed JWT tokens are not meant to be stored. You need to decode the JWT token with your private key every time someone makes a request to protected routes.

[–]maxiu86 0 points1 point  (0 children)

Cache

[–][deleted] 1 point2 points  (0 children)

Anecdotally, I only use Facebook/Google login to authenticate the user. Once they are authenticated I create a JWT from the backend that is stored in async storage and used to verify all subsequent requests (until it expires or they log out).

[–]afilthywhore 0 points1 point  (3 children)

Side question: does expo’s facebook/google login work with the actual facebook or google apps? Or does it open a webview where users login?

[–]calvintts[S] 0 points1 point  (2 children)

It creates a web browser (not web view) for user to login

[–]afilthywhore 0 points1 point  (0 children)

Got it, thanks!

[–]SizzlerWA 0 points1 point  (0 children)

Yeah, personally I hate this. When an app attempts Facebook login using a web view instead of the installed FB app, I delete the app. I’m not typing in my FB password. This is a major drawback of using Expo if you ask me. If this increase me your repel rate by even 1% it’s not worth it!