Session IDs
Read about Session IDs which is a simpler choice for securing data exchanges
Overview
A web application typically uses session IDs to maintain and manage cookies (sometimes access tokens depending on the approach). Session IDs are managed by the app developer’s library. As an example, an integrated AuthN app receives data after authentication, pulls out what they care about, and stores this information in their session. The following AuthN response data helps create sessions:
- user ID
- email address
- name
Session IDs are long, unique, and random strings that don’t provide user information. When a server receives a session ID, the server usually does a database lookup to correlate the session ID with the user and to figure out what the user can do. In contrast, this extra work is not required for JWTs - which are self-contained and include the user information (in an encrypted form, of course).
Key features
- Created and managed by the web application
- Easy to delete
- More simple to manage than JSON Web Tokens (JWTs)
Sessions IDs are best for:
- Easier to manage across a large-scale distributed system
- Organizations or apps that lack the resources to build or use a strong key management system
- If your company lacks the resources to build a strong key management system
Session IDs are easier to manage because JWTs require you to properly store and distribute private/public keys that are used for signing and verifying, which can be difficult on a large-scale distributed system.