For what design reason is Asp.Net Core SessionKey different than the SessionId?

[rclabo]

The DistributedSession class uses a sessionKey Guid as the primary key for the sqlserver table that ultimately gets used to store sessions. This Guid is generated by the SessionMiddleware class and passed in to the DistributedSession . This SessionKey Guid is a different value than the SessionId . The SessionId Guid is generated by the DistributedSession class.

Why?
What I want to know is why is the system designed this way? Why isn't the SessionId and SessionKey the one and the same? Why use two different Guids? I ask because I'm creating my own implementation of ISession and I'm tempted to use the SessionKey as the SessionId in my implementation so that it's easier to match up a record in the database to a session. Would that be a bad idea? Why wan't DistributedSession object designed that way rather than generating a SessionId that is different than the SessionKey? The only reason I can think of is perhaps trying increase security by obfuscating the linkage between the database record and the session it belongs to. But in general security professions don't find security through obfuscation effective. So I'm left wondering why such a design was implemented?

I have posted the stackoverflow question here: http://stackoverflow.com/questions/42590026/for-what-design-reason-is-asp-net-core-sessionkey-different-than-the-sessionid if you would like to answer it there.

[Tratcher]

The lifetimes are different. The true lifetime of a session (and SessionId) is controlled by the server. SessionKey is stored in the cookie and lives on the client for an indeterminate amount of time. If the session expires on the server and then the client sends a new request with the old SessionKey, a new session instance with a new SessionId is created, but stored using the old SessionKey so that we don't have to issue a new cookie.

Put another way, don't depend on things outside of your control. The client can keep and replay their SessionKey indefinitely, but it's the server that decides if that is really still the same session.

[rclabo]

I appreciate the information. Thanks.