Dev Agrawal 0:05
Thank you very much. That was an amazing intro, Dan. Hello, everyone. We are talking about signing sessions, which to me are this is just the title that I’ve given them. That’s I think they’re the most powerful authentication tool available to us that we just heavily under use. Right? Hi, I’m Dev, and I’m a dev. I’ve been like Dan mentioned, I’ve been writing full stack apps for a while now. And I am currently working as a developer advocate at Turq, building full stack authentication solutions for React. And that there’s my YouTube handle devagr, you can find my videos where I talk about software development, web development, talk a lot about architecture, which, which has kind of influenced a lot of my thoughts that I’m going to be talking about today. And I mostly should post on Twitter, but I also sometimes post valuable things. So you can also follow me there. It’s called X now, I guess. So yeah, the session.

Dev Agrawal 4:31
The goal of this today is really to explore what an art system what an art system looks like that goes beyond just a very simple sign in sign up system and has a more fleshed out session management capability, like device tracking, and how we can implement session tracking session management without requiring additional infrastructure like have Redis cache or things like that. This is going to be obviously the most helpful if you’re implementing your own customized solution. Because then you can you can incorporate some of these concepts into making your own od system level up. Or, if not, you can also if you’re using an Auth provider, like lurk or like fish or not, then this talk is going to give you a more deeper insight into how these auth providers work, and how they make their under the hood magic happen. So let’s start with some basics. What is a session? Well, a session really is just an abstract concept. It’s, it’s the period of time or the duration of time between signing in and signing out. That’s really just now, the thing that I really love about abstract concepts is that the thing that I really love about programming actually, is that we can easily turn abstract concepts into concrete concepts. So for example, we have, we have concrete things like a user a product or a review, and we represent them into our software in our code. But then we also have abstract concepts like a line item, or a transaction. And similarly, the thing that we’re talking about today, a session is just an abstract concept that we can model that we can track, and that we can use in our application to do stuff. I have a little bit of a cough, so I might stop by to get that out of my throat. So yeah, let’s, let’s look at what we can do with this session object. The first thing, I’m sorry, my Alexa triggered for some reason.

Dev Agrawal 6:48
So the first thing that we can do is when someone signs in, because that’s the moment that we create a session, we can just create that and store it in our database. And then when we’re signing out, we can give it an end date, or we can have these created a date for the session and an end of that date. And this is a an easy way to keep just keep track of sessions. And by the way, these code examples I’m using is Typescript and Prisma. But all of these examples apply to really whatever language or whatever tool database that you’re using. It’s just a general idea that whenever we’re signing in the, let’s say, the example on the left is your sign in function, sign in handler, whatever, however you have that implemented. But in that middle somewhere, after you’re done checking the credentials, you can create the session object and store it in your database. We’re not yet using it for authentication, we’re just using it, let’s say to keep keep track of stuff. But now, now that we have this kind of, we’re saving the sessions in the database, we can start showing or users the list of active sessions. So for example, if I log in to an app, I might see something like this, you probably probably don’t want to show the session ID itself. It’s just there for demonstration purposes, that these are two different active sessions right now. And when they were created, so we can start showing them users simple stuff like that. Maybe they can, we can, maybe it can help them identify when or where they’ve logged into the application, so that they can track any unwanted silence. But let’s take this a step further. Let’s also store we can use that CDB request object and grab some headers from it. And we can start storing the user agent and X forwarded for which is basically the IP address of where the user is accessing the application from. So now we can even show that information. So here you can see that I’ve logged into my account from a Mac, which is what I’m currently using, and from an iPhone. And on the left, we can just, this is really just very basic, checking the string if it has a Macintosh string. And if that’s the case, we’re going to show the Mac icon, if it has an iPhone, we’re going to see show the iPhone icon. And you can parse these headers, they have a very specific format, so you can parse them to show the information in a more useful way. So instead of just dumping that entire HTTP header, you might want to show that okay, this is an iPhone in a Safari, or this is a Mac with a Chrome browser. And then show me even more helpful icons maybe. And you can also show the IP address and maybe you can use the IP address to show the location or of this is the location that the that you accessed or that you logged in from so that it makes it even easier to track any unwanted signings or to make sure that have only the devices that you actually own are signed into your account. Let’s, maybe now we can start using these for some actual authentication. So let’s go back to our sign in and sign out handler, or really just the sign in handler here. Oops. Yeah.

Dev Agrawal 10:22
So once we create s session, all really all we have to do is to set a cookie, we can take the ID of the session and put that in any cookie that we want. And the next time that the server receives the request, we can grab that cookie out of the cookies object, and we can check first of all, we should check if the cookie even exists. And if not, we throw an unauthorized setter, then we fetch the session object that’s that the cookie corresponds to. Now if the session object doesn’t exist, then obviously, that’s a bad cookie, or maybe someone is tampering with the cookie. So we just sign them out, and we throw the unauthorized letter. Or if the session has an end of that date, which means you have already signed out of that session, you shouldn’t be able to use it to authenticate with requests. So in both of these scenarios, we will just unset the cookie so that future requests don’t have to go through this process again, and we throw the unauthorized error, so that the client knows that the user needs to sign it again. And of course, if none of those things happen, authentication was successful, and we can continue the operation.

Dev Agrawal 11:38
Okay, now, we can actually start implementing more useful things like revoking a session. So for example, we can add this sign out of this device, the link or button on all of these all of the sessions that we’re showing them. And all really we have have to do when you click on this button is just set that ended that date. And I’ve also added this extra field here called status, which we can just use to keep track of whether Did you just sign out of this device, like on the device directly? Or did you remotely sign out of using a different device, like if this was an unwanted device and login, or if you logged in some on some public computer, and you won’t need to sign out of it, or your device got compromised, so we can keep track of whether you revoked the session, or whether you manually ended the session, which is why there’s two different examples. The first one is to revoke the session, which is what happens when you click on the Sign Out of this device button. And the second one is the the Sign Out button. In which case, we also want to unset the cookie, so that the next time you were on this application, you are showing the login screen instead of the actual protected screens. So this is the classic session based authentication that we know and love. Right?

Dev Agrawal 13:05
So what else can we do here? Yeah, we can even add things like session timeout. So maybe if you if we want the sessions to only be valid for let’s say, 24 hours, as in this case. So whenever we’re doing some sort of an operation, some sort of an authenticated private operation, we’re going to fetch the session object, just like we did in the example before. And we can check the creator that date, and check that if the if the creator that date was more than 25 hours in the past, then we are just going to simply throw an error saying that you are unauthorized, or you actually, you probably want to show a lot more helpful errors here. These are just for demonstration purposes, very simple errors. These are not even stdp errors. But you get the idea that you want to throw an error here saying that it’s been too long since you’re signed in and you need to sign in again. In this example, here, we’re doing it only for 24 hours, but you probably want something like a week or a month, or if it’s a really sensitive application that you’re building. If it has something to do with finances, banking, credit cards, then you probably want to keep it down to maybe 15 minutes or 20 minutes. Okay, what else can we do we can also do authorization. So now that we we have a session object and we are fetching it right before doing anything important with it. We can also store additional information in there that we are going to use for role based or attribute based access control. So in this example here, along with signing in, we are also the user is also going to sign in to an organization that they are a part of it as maybe this is a b2b application. In that case, we’re also going to get them their organization membership, which will give us their the ID of the organization that they’re a part of, and their role within their organization. And instead of having to fetch that information, instead of having to go back to the database to get that information, whenever we receive a request, we can just throw that information into the session object. So that then so that the next time when we are doing some sort of an operation, like on the second example, you’re doing an admin operation, we can just check the session role, instead of doing a second fetch for the user membership object. And you can do this with any additional information you want. Maybe if you have a location based or time based access control, you can add that information in the session object itself. And because we have that information in the session, and the session is stored in our database, we can even update it while the user is signed in. So for example, if while you’re signed, and you receive some sort of promotion, or your access levels are elevated, or maybe you got laid off, and all your access needs to be revoked, we can update, I hope that doesn’t happen to anyone watching, or anyone in here. But if that happens, we might want to handle that. And in that case, let’s look at the example on the left.

Dev Agrawal 16:35
And in the example on the left, the user is actively switching the organization that they’re in. So maybe in a b2b application, you can be a part of different organizations. So you can switch the organization from say a to b. And if that happens, we can just get the current session that you are signed into. And we can update the organization ID and the role ID within that session. So that the next time you make a request, you are in this in this new organization instead of the old one. In the second example, we are changing the role of a user. Now this is happening, let’s say externally, so maybe if your role is changing, it’s probably someone else who’s actually changing the role and changing your role in the system. So we are going to the server will have your user ID. And we can tell we can tell the server or we can tell the application to go and find all the currently active sessions. So which is why we have the end of that is null. And the user ID so for either your user ID and the org ID. So whatever person is changing your role, whatever organization that happens to be in, we’re going to look for all the active session objects that match these parameters. And we’re going to change the role property to the new role that you have just received. So that once again, as soon as you you make another request with application, that application will have your new role instead of your old role. So we can see that implementing session management or session session authentication, like this gives our app the ability to react to session policies or access policies that change in real time. And this is not something that we can do with traditional token based authentication. And we’re going to get into that soon. But the main point is that all of the all of the data that we need for permissions or for access checks is right there in the session object, instead of being instead of being in a different object, and us having to do another round trip to the database to fetch that data. So this is kind of what it looks like, the client sends a risk sends a request to the server, the server will fetch the session object, it will validate it, which is basically making sure that the it doesn’t have it’s not already ended, or it’s not expired, or things like that. And once it’s validated, we can do the actual action or we can fetch the data that the client has requested. And we can send that back as a response.

Dev Agrawal 19:20
Now let me talk about how this is in contrast with token authentication, because you might have seen some comparison charts or blog posts about session authentication versus token authentication, and the trade offs between them and when you might use one or the other. Session authentication is stateful, which is demonstrated here which is unique. You need to or the application needs to fetch the session object from a session store, which might be your database. Now, the problem with it being a database is that it You’re going to have, it’s going to be a bottleneck, because every single request that’s hitting your server, or at least every single authenticated request, will need to query this session store to get the latest session object, and then validate it, and then do anything else. Now, because every single request is going to be doing it, it’s going to become a bottleneck, which means unless you are you are paying really, really close attention to your database performance, this is going to be a point, which is this going to be a performance bottleneck, and maybe even a failure bottleneck for your application. Which is why oftentimes, we’re going to see developers implementing this with a Redis cache or a Redis Database, or some sort of an in memory implementation of that, because it’s usually much faster to read from those databases. And because sessions are not really things that we update very often, we just talked about, like maybe your session gets revoked, or maybe your permission gets the permissions get elevated already, or revoked, or something like that. But that doesn’t really happen too often does it. So it’s fine to keep these things in a cache.

Dev Agrawal 21:12
But even then, you still have an overhead of making a request over the network. So there’s still a round trip latency included in every single request that you have to make. Now, you can kind of go work around this by literally just keeping it in memory, instead of offloading it to a different data store, like Redis, or like a regular database. But that’s going to only work if you just have a single server. If you have more than one service, if you’re trying to scale out horizontally. Now you’re gonna have to synchronize state between them, which is a whole different pain. And you were probably better off just using Redux. But the thing about token authentication is that is that I don’t have a slide for it. I thought I did. But basically, if you do the same thing with tokens, then basically, you’re just completely eliminating the fifth session part from the session store. Because the idea of JSON web talk tokens, or JWTs, is that they cannot be tampered with. So whenever you receive a request from the client, you’re actually going to have all the information that’s needed to authenticate that request in that request in the form of the JWT. So instead of validating the session, as we’re doing in here, you’re going to be validating the token, which is much faster than making a request over the network on a session store. So let’s go through, let’s walk through some other some more comparisons of what this might look like. So here we have, we are storing the session on the server, let’s say you’re in the org ID two, and you’re you have the role of user, the client makes, the client tries to do a user action and succeed. But if you try to do an admin action, it’s going to fail, because obviously, you have the role of the user, not the admin. However, because the session is stored on the server, as a server state, we can update that halfway through. By the way, the x axis here is time. So you can imagine the left being the left being when you’re signed in, and the right extreme being when when you’re signing out. So even before you can, you can see that we can update the role, or you can get a an elevated permission. So in this case, at this midpoint, the role changes from user to admin. And now you can actually perform both user and admin actions.

Dev Agrawal 23:53
You can also just completely revoke the session at any point. So any action from that point on is going to fail, because the session no longer exists, you either signed out, or maybe you revoked the session remotely, because it was a it’s a device that you’re no longer using or something like that. Now, that’s how it might work for the server. But if you’re using a token based authentication, if you’re using JWTs, that session object actually lives on the client. And the server has no record of that. So you can’t really touch that, or touch or do anything with that state. If you’re if halfway through your role, or the user role changes to an admin, the token there is no way for us to update the token with it because the server has no state that there is a token being used, which is why token based authentication is often used for machine to machine communication, or when you have when you’re making an API call on the server to a different server However, you’re going to see a lot of these comparisons, but no one’s going to tell you that you can actually do both session and token based authentication, and you can get the best of both worlds. So if you’re if you’re stuck around this far, I’m going to introduce you to your new best friend, or at least my new best friend called the short lived token. And this is kind of how it works. So in this new scenario, we have both the servers state, or we’re storing the session state on the server, it could be inside, it could just be in a plain database table, it doesn’t even have to be something fancy like a Redis Cache. Because we also have a token that represents that session object. But the trick here is that the token actually doesn’t live for the entire lifetime of the session. Instead, the token is pretty short lived, which means maybe it only lives for 60 seconds, a minute.

Dev Agrawal 26:01
So here, you can see that after a minute, the client needs to regenerate that token, it needs to go back to the server and fetch a new token. So we’re going to, we’re going to see some of those same examples here, the user action, it works, but the admin action still doesn’t work. Because the session, the session knows that that role is a user role, not an admin role. However, if the if the server state happens to change, and if you receive a new rule, the next time the client generates a new token, with that session, it’s going to be it’s going to have the new data. So this time, you’re seeing both user action and the admin action succeeding. Finally, once again, if you revoke the session at any point, or when you sign out, you’re only going to have the JWT that you currently have for as long as you do. But the next time you try to regenerate a token, it’s going to fail. And you’re not going to have any tokens at all, which means you can no longer make any user actions. So this gives us the best of both worlds, because this allows the token to change and update and reflect any changes that happen to the server state, because the token is just a snapshot or a cache of, of the server state. But it also eliminates the overhead or the traffic of creating the server or creating the database, or some sort of a Redis cache for a session every single time. Because we’re just using plain old JWTs, it just happens to be that those JWTs or those session tokens, as I like to call it, a are just short lived. And the client is responsible for keeping them up to date. In this, I’ve chosen the example of one minute or 60 seconds, but really, it can be as long as you want. The main the main idea is that the client will have some sort of a background process or loop to make sure that the client that the token is updated. So if the token is 60 seconds, left for 60 seconds, then the client might want to receive a new token every 50 seconds, just to make sure that you always have a working token to use.

Dev Agrawal 28:24
So we have shifted the responsibility. Or we have shifted the overhead of having to go to the database and fetch a new session object and do something with it asynchronously instead of being instead of it being something that happens during a request. The so I talked about the example of using 60 seconds or one minute. And this is something that you can change, obviously, however you want. I use the example of 60 seconds because that’s what Clerk uses. But the idea of the 60 seconds is that’s how long, that’s the maximum possible duration of an inconsistent authenticated state. As you can see, in the in the example here, there’s going to be a period of time between when the state on the server changes. And when that change is actually reflected on the client. Because of because of the mismatch between when the server state can happen, which can happen at at any time. And when the client decides to update and get a new token based on that. The 60 seconds or whatever time limited choose is really the maximum you have most more often than not that it’s going to be much smaller than that. And we’re going to look at some other examples in a bit. But if for your use cases, 60 seconds is too long. You can make the short you can make the short left tokens be like just 20 seconds or 30 seconds. So you’re going to be refreshing your tokens more frequently. But you’re going to have shorter inconsistent odd states, maybe for some applicate. For most applications, it’s probably fine for it to be one minute or even five minutes. I know some auth providers have short lived tokens for up to five minutes, characters per minute. And maybe you’re in some really highly regulated or highly secure context where these inconsistent odd states are really like a no go. And you really cannot have that kind of like, even like five to 10 seconds of inconsistent odd states, in which case state to enter this cash. But most more often than not, again, the short lived tokens make the correct trade offs in that by by trading off the those really infrequent or really rare scenarios where you’re authenticated stated, your authenticate key, your authentication status changes on the server. And it needs to be really reflected immediately on the client. You’re trading off, not having to deal with a lot of infrastructure complexity, and being able to have really performant authentication, because you don’t have that overhead of fetching the session object on every piece on every request.

Dev Agrawal 31:17
Now, having these short lived tokens gives us an additional capability, which is because the client is now basically poking the server at every minute or so said, Hey, I need a new token, hey, I need any token. If the client doesn’t do that for a while, the server can probably assume that the client is inactive. Or you may be tapped out of it or you’ve closed the browser tab, or you just shut off your computer and you’re doing something else without signing out. And in this case, the client might need to add, incorporate some additional logic, like maybe if you put a tap on the background, the client should be able to detect that and not need to constantly fetch a new token, violets in the background. Because right now, you can probably look at your Chrome window and see how many tabs you have in the background, right now. Imagine if all of them were constantly refreshing new tokens, they don’t really need to, I have zero by the way, I really try to keep my browser tabs clean. I don’t know why I just get freaked out if I have more than six pairs of tabs open at any point. But I know that’s not the case with most of the people. But basically, because we now have this indicator of inactivity, we can use that to do some more interesting stuff. For example, we can the page where we were showing the user, this is the device that you’ve logged in with. And this is when you’re logged in, we can even show an indicator of when when was the session last active. And we can do that by by simply storing the timestamp of all these blue arrows in the session. So we can store a timestamp of or we can keep track of when was the session last used to generate a token for the client or for any client.

Dev Agrawal 33:11
And we can even have inactivity timeouts. So we can say that if you’re inactive for more than 15 minutes, you now have to sign in again. And we can do that by adding a check here saying that if the last time that you use the session to generate a token was more than 15 minutes ago, you now have to sign in again, the session is no longer valid. So it’s similar to this total session duration check that we had earlier. The only difference is that we were using the session created at timestamp. But here we can use when was the session used to generate a new token, which probably needs a much better name. But naming things is hard. So and we’re already dealing with cache invalidation here, so I don’t want to tackle two difficult problems at once. Alright, so that’s really kind of the most of the things that I had about sessions. The first was, obviously we should try to model and keep track of sessions so that we can show our users interesting stuff. We can give them more control over their account and how how was it? How was that account logged in? What devices was logged in from? When was it logged in? When was it last active. And obviously add things like authorization attributes, so that we can save additional round trips to the database. And finally, we can save the trip to the database to fetch that session object itself by using short lived tokens. And I really hope more, more auth systems start using short lift tokens because it’s just a really nice way to not have to deal with additional infrastructure like Redis caches while still being still having that full access to. Okay, I’m going to revoke this They shouldn’t, or I’m going to update the permissions on this without that overhead, because short left tokens really are just snapshots of the server state. And that is the last slide I have. I hope that was an informative talk. I’m sure there’s there’s going to be a q&a session now. I’m looking forward to hearing all your questions. Thank you very much.

Dev Agrawal 35:22
Thank you so much, Deb. That was That was amazing. Thank you. Definitely, if you have any questions, if you’re following along, please type them into the Crowdcast questions area, I have a couple of questions myself. So I’ll probably kick something off. I checked, and I didn’t see anything right now. But

Dev Agrawal 35:44
I see a lot of interesting people in the chat. Hi, Henri, hi Cassidy.

Dan Moore 35:50
Doing the shout out to the audience? It’s awesome. Um, so can from the start, you kind of talked about device metadata and storing that in sessions. And I wondered if you were concerned about the integrity of those headers that you’re storing in the session?

Dev Agrawal 36:07
Yeah, the something that I had in my notes, but I forgot to bring up said that if you’re if you’re using those headers, definitely check out the MDN Doc’s. And there’s a bunch of documentation around using these headers properly, the X forwarded for it’s an important one, because, first of all, obviously, it’s an IP address. So you got to make sure that you’re storing that securely, and don’t accidentally leaked that. And it’s a it’s basically a sensitive thing, like even in my demo, I had to redact it. But also, there’s a lot of things like reverse proxies at play. And I think the proxies, there is trusted proxies try to do their best to maintain the header. But if not, again, there’s documentation around how to handle that. And same thing with a user agent, you might have like, some proxies in between that mess with it. And sometimes you just can’t really do anything about it. Because the users this one really wants to hide what device they’re using, and we gotta respect that.

Dev Agrawal 37:11
So is it fair to say you can use that for informational stuff, but you shouldn’t build like a security model on whether someone’s coming in from a Mac? Or an IP address or something like that? Is that fair to say?

Dev Agrawal 37:21
For sure, yeah. That’s really up to the user. In that case, that, Hey, you, you didn’t really tell us what device you’re logging in from, that’s the best we can do for you Sure.

Dev Agrawal 37:34
had a question from the audience? Sue asked are short lived tokens more secure than longer lived ones.

Dev Agrawal 37:42
So they’re definitely more secure just because they they don’t live as long. So if someone happens to grab them, if someone like, comes in between and steals those tokens, they won’t be able to use them for much longer. And if someone gets unauthorized access to your account, they’re only, they’re only going to be able to use it for a maximum of let’s say, 60 seconds, or whatever the duration of the short lived token is, so they’re more secure. But like most things, in like, in computer science, it’s a trade off because it’s more secure by the fact that you have to do more work, just to make sure that you always have up to date tokens.

Dev Agrawal 38:27
Great, great question. Thank you. So yeah,

Dev Agrawal 38:28
yes. With a new Yes. With a big star.

Dev Agrawal 38:32
Yes, but it’s more work. It makes sense. Cool. Another question I had is, we talked when you’re talking about kind of the pure session approach, where you’re always going back to the database, you were saying that, you’re going to make the database do a lot of work. And when I was thinking about it, I was wondering if that was different than any other scaling of a database, or whether there were specific things about the way sessions are used that made it additional extra hard or extra considerations to think about.

Dev Agrawal 39:07
So it, it’s not really like, extra hard or anything like that. It’s really just like you’re doing, you’re doing the same thing on every request. And there are ways to mitigate this. So we should be so for example, like putting putting a cache in front of it. Because this is data that doesn’t really update that often. The thing with every other piece of data is that it’s really use case specific. So I can’t really offer general advice like that, that, hey, you just just put a cache in front of it, or just put that in a token and you’re fine. Everything else is really use case driven. So it’s hard to optimize around this stuff. But the thing about sessions is that it’s kind of a solved problem, like authentication in general, is mostly a solved problem. And we have a lot of ways to optimize around the stuff like fetching sessions from the database constantly. And the other thing is that this really happens at for every single request. Some of your requests might not hit your primary database. Some of them, you might have different databases, you might just be uploading files, in which case you’re not touching the database at all, or there might be a lot of other things. But you’re, you’re probably always hitting your session database. So it’s a combination of how often this happens. Plus, does it really need to happen at all? If you can just use a token? Why not? Let’s just eliminate one over one round trip to your database while we can.

Dev Agrawal 40:38
Great question. Another question from the audience. Antonio asks, How is the best way to manage or coordinate short lived token requests? In particular, how do you prevent multiple tabs from sending all their short lived token requests by themselves? Or avoid? I would what I call the Thundering Herd Problem, right? Like we have a bunch of things happening at once.

Dev Agrawal 41:03
Yeah, yeah, and this is just this is just a problem that requires, you know, you either have to use some some sort of library that does like reactivity tracking, or you have to do some fancy stuff around. Like, you not only need like a 52nd timer, or 52nd loop, just to make sure you’re constantly refreshing the token. But you also need some checks around is this browser tab active? Or do? Did you already make a request somehow. So this does require some fancy programming to make sure you don’t do you don’t need to request, you can use libraries like FFTs, maybe, or anything that does like the fancy concurrency and effect tracking or retries, anything like that. Or you can try to build it on your own. I don’t recommend that. Overall, I just I don’t recommend trying to implement on your own. But if, if you really want to do all of this, this is not really something that I’ve really dug deep into. So I can’t really offer tangible advice here. And as for like, keeping track, but between browser states, if you’re, if you’re storing these tokens in the local storage, then you you can probably just check if, if there is a token existing in the local storage or in your cookies, then you don’t need to go and fetch a new one. Or maybe you can also store when was this last updated in the local storage, so that you can keep track of that. Or most of the time, you probably you’re probably just storing it in your memory. So you’re not storing it in the local storage, in which case, every browser tab is going to be fetching its own its own session token on its own loop instead of coordinating between them. So this is more of a trade off that you might have to make. Maybe you don’t want the browser tabs to to share the session token, maybe you want them to have two tabs open where they can be logged in, they can be signed into different accounts, or different organizations, but on the same application. So it may be you want to keep them separate. Maybe you want to keep them together.

Dev Agrawal 43:19
So kind of a follow on question for that is you can throughout one library, but is there any as clerk solve this problem? Is it like Super Business domain specific? So it’s not a generalizable solution? Are there other libraries out there? you’d recommend people look at for that problem?

Dev Agrawal 43:35
I mean, yeah, I’ll definitely say that clerk has solved this where like, a lot of the what I talked about, is heavily inspired by, like, what I’ve how I’ve seen clerk implemented. I’ve even wrote an entire blog post on this, on the clerk website, on how clerk implements session handling, which is, like most of the blog posts is basically this talk, but in written form. So clerk definitely has that salt. But like, also has like, like some of the trade offs that I talked about, where you might want different browser tabs to be completely independent from each other, or you might want them to share some stuff. It’s a little tricky to get around. But for like 90% 95% of the use cases, Claire cast us down. And any other library or any other Auth provider, or art library that’s using short lift tokens. They probably have this all, too, to a big extent.

Dan Moore 44:34
Yeah, I was asked in particular about the extra tabs thing, but I understand clerk has all this. And hopefully, we can get that blog post up and share it on the CFE.dev website. That’d be that’d be great.