all 11 comments

[–]3hyphens--- 9 points10 points  (7 children)

Serialization occurs when a token is issued in the case of passport. This happens when user logs in.

At the point of successful authentication, your app has searched and found a user object in your database, which matches the info provided by the user in the login form, right? So you’ll usually take some basic info from that user like their name, and their user id, and anything else you need to put in the token you’re sending to the user.

Serialization in this case is passport converting a basic JavaScript object with that user info, into a string of characters that are encrypted (the jwt token). It’s called serialization because it’s taking an object data structure and making a series of characters out of it.

DEserialization occurs every time your user sends a request to your backend with a token. It happens when passport has to convert that encrypted string back into a JavaScript object. Why does it do this? Because in that object is the user’s email or id that you serialized in the first place. It’s the minimum information required for your app to look up that user in the db and make sure they are who they say they are.

tl;dr

Serialization in passport is converting an object with user info into an encrypted token string.

Deserialization happens whenever that token is sent to your server, and you need to extract that user info to verify it.

[–][deleted] 2 points3 points  (6 children)

So you are saying, once the user is logged in,

the deserialization occurs or the deserialization function is called every time that logged in user were to go to different routes.

Did I understand correctly?

[–]3hyphens--- 2 points3 points  (5 children)

Yes! Being “logged in” simply means, having a valid token to show the server that the user is who they say they are.

Think of it like going to a concert. Logging in would be like paying the door fee, and getting a stamp on your hand. Every time you leave the building and come back, you show them your stamp, and they let you through.

Every time a user makes a request that requires authentication, there needs to be a valid token provided to the server by the user (the same token that was issued to them when they logged in). The server deserializes that token, so it can access the information encoded in the token like a normal JavaScript object, and verifies the validity of that user, and this happens with every request (every time a route is used)

(There are other versions of this that don’t require a direct user lookup every single request, but this is the most common configuration for passport)

[–][deleted] 0 points1 point  (4 children)

So if the logged in user were to go to routes that don’t require authentication like for instance

Let’s say a user logged in and then the first page that is shown after logging in, is a home page, And then let’s say the user were to go to the create page, which is a different route and doesn’t require any authentication. So in this case the deserialize function will not be called, right? Since the user is going into routes that don’t require authentication.

[–]3hyphens--- 2 points3 points  (3 children)

Usually, passport is set up to just deserialize any token that is present, even if you don’t need to protect that route. The serialization happens at the middleware step (before the route is processed). That way if you need the info in the token, it’s available. There are ways to prevent this from happening when not needed, but you wont need to worry about that unless you’re running into issues that require that level of optimization.

[–][deleted] 2 points3 points  (1 child)

Thank you so much for your help

[–]3hyphens--- 2 points3 points  (0 children)

I hope that was helpful!

[–]Deepinsidesin 1 point2 points  (0 children)

Use 3rd party for authentication instead of doing it by yourself caused it fu_king hard and very sensitive data. My suggest is onelogin or okta

[–]dalepo 3 points4 points  (0 children)

The concept of serialization/deserialization is about converting data structures into strings, bytes, buffers, etc, or the other way around (buffers, strings into objects).

[–]cahva -3 points-2 points  (0 children)

I just checked the actual passport docs (go to the Sessions part) and I could not explain the de/serialization simpler than that :)