I'm on the faculty at Boston University in the computer science department, where I teach software engineering, intro courses, and application architecture and development. Also a bit of a Deadhead.
Thank you! The technique would be the same for multiple login paths. Once the user is logged in via a local user/password or a third party, generate the JWT. It's independent of the login method used.
If you are using Passport, its serialize / deserialize methods are a good spot to put JWT processing. As Alex pointed out above, sending the actual access token from a third party back and forth is not a secure method, and so you would want to store some identifying data in the JWT such as the user name or other unique value.
The JWT generation in the example code is done inside a Twitter OAuth callback; in your case with multiple providers you'd want to move that out into its own function that each callback (and your local user / password method) would invoke.
Your question has me thinking again about what responsibilities the JWT checking code should have...I'm starting to lean toward that function placing a user object with relevant user info (fetched from the database) onto the request along with an 'isAuthorized' boolean so that each route could decide what to do next.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thank you! The technique would be the same for multiple login paths. Once the user is logged in via a local user/password or a third party, generate the JWT. It's independent of the login method used.
If you are using Passport, its serialize / deserialize methods are a good spot to put JWT processing. As Alex pointed out above, sending the actual access token from a third party back and forth is not a secure method, and so you would want to store some identifying data in the JWT such as the user name or other unique value.
The JWT generation in the example code is done inside a Twitter OAuth callback; in your case with multiple providers you'd want to move that out into its own function that each callback (and your local user / password method) would invoke.
Your question has me thinking again about what responsibilities the JWT checking code should have...I'm starting to lean toward that function placing a user object with relevant user info (fetched from the database) onto the request along with an 'isAuthorized' boolean so that each route could decide what to do next.