Session IDs are usually just a random (opaque) identifier that is passed between the client and the server. The server uses the identifier to look up state information (e.g. current cart content) in the database.
As a practical matter, you have to trust that the client will protect the session id, as once you send it to them, it becomes a static token -- no amount of cryptography can fix the fact that anyone can present a session id and then pretend to be the user.
There are some things that you can do to mitigate issues:
ensure you are using a "secure enough" random generator to build the
token
make sure the transmission of the token is as secure as possible against eavesdropping or client-side theft (e.g. use SSL, httponly and secure cookie flags)
Give the token a reasonable timeout, and require the user to request a new token periodically using e.g. a refresh token or re-login.
A lot of thought has gone in to how this can work practically - have a look at the OAuth2 / OpenID Connect protocols.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…