Skip to main content
Information Security

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

9
  • While you make a good effort to add some context to ThoriumBR's answer that might help somebody understand how OAuth tokens and JWTs are different (especially given that OAuth tokens are frequently JWTs), the part about server side sessions and client side sessions seems to skip a few things. Both opaque and structured tokens can be used to implement either server side or client side sessions. Every session that holds data is stateful, it is the server (the authorization server, not necessarily a resource server) that is stateless. Commented Nov 9, 2022 at 14:44
  • @Buurman how can you implement client side sessions with opaque tokens? Commented Nov 9, 2022 at 14:45
  • You simply store the data you want to store clientside, in clientside storage, linked to the opaque token. You don't need to store it in the actual JWT. Commented Nov 9, 2022 at 14:50
  • @Buurman So how will the server retrieve the session data from the client side? Commented Nov 9, 2022 at 14:54
  • 1
    Why would the server need to retrieve the data? If you want to send it to the server (say, as filter option for a GET call) you can just send it along in the request. If you want to save part of it (say, a persistent preference) you can just POST it to a relevant endpoint. But you can easily keep most (if not all) data clientside only. Note, I'm not saying this is good for every situation, or even my personal preference: I'm just saying it's a somewhat common variation. Think of mobile single player games that have you login but store your progress clientside. Commented Nov 9, 2022 at 15:03