3 ms·

> Opaque tokens don't carry _anything_. Opaque tokens are opaque to consumers. There’s no limit on what can be in there, as long as they’re opaque. So yeah, yo

by dfee 4y ago

> Opaque tokens don't carry _anything_. Opaque tokens are opaque to consumers. There’s no limit on what can be in there, as long as they’re opaque. So yeah, you don’t need that token to just be a PK. It can be a real payload (generally encoded).

Octoth0rpe 4y ago
> Opaque tokens are opaque to consumers. > It can be a real payload (generally encoded). Based on your definitions, a JWT is therefore a specific kind of opaque token. I don't think it is personally. I think we really should be talking about tokens as falling into two categories, of which JWT is an implementation of the first: 1) stateless - the token contains meaningful content that can be verified by a consumer. JWT is such an implementation with a standardized way of verifying the content without additional database queries (excepting revocation here) 2) pure identifiers - the token is merely an identifier, and all consumers must reach out to some other service (eg redis) to retrieve the details/capabilities that the session should have. Edit: alternative proposed terms: content-full, content-less
- jimbobimbo 4y ago
  Opaque token is called opaque for a reason - only the issuer knows what's in it, whether it has content or not, is it an identifier or an encrypted payload, what to do to make use of it. Content-full and content-less break that abstraction.
  - marcosdumay 4y ago
    This is a hard area to work on, everybody that says something apply their own meanings to the words, you can never know what anybody else says. Anyway, I have always understood it as the token being opaque for the verifier too, that only ever tested it for equality. The token that is opaque only for the holder is normally called "encrypted". It may not be opaque to the issuer, but that doesn't change much. But anyway, depending on what you read, you will get different meanings.
    - P5fRxh5kUvp2th 4y ago
      > Anyway, I have always understood it as the token being opaque for the verifier too Which falls flat on its face the second you realize the "verifier" can pull out information based upon that opaque token. It just means the intent is not for the person receiving it to do anything except reflect it back on subsequent requests. That's it. Typically it's done by handing something that is meaningless without context, said context not being available to the consumer being issued the token. But there is absolutely nothing that says you can't hand them a JWT meant to be used as an opaque token. If you're really worried about it, encrypt that bad boy before giving it to them.

by dfee 4y ago

Octoth0rpe 4y ago

> Opaque tokens are opaque to consumers. > It can be a real payload (generally encoded). Based on your definitions, a JWT is therefore a specific kind of opaque token. I don't think it is personally. I think we really should be talking about tokens as falling into two categories, of which JWT is an implementation of the first: 1) stateless - the token contains meaningful content that can be verified by a consumer. JWT is such an implementation with a standardized way of verifying the content without additional database queries (excepting revocation here) 2) pure identifiers - the token is merely an identifier, and all consumers must reach out to some other service (eg redis) to retrieve the details/capabilities that the session should have. Edit: alternative proposed terms: content-full, content-less

jimbobimbo 4y ago
Opaque token is called opaque for a reason - only the issuer knows what's in it, whether it has content or not, is it an identifier or an encrypted payload, what to do to make use of it. Content-full and content-less break that abstraction.
- marcosdumay 4y ago
  This is a hard area to work on, everybody that says something apply their own meanings to the words, you can never know what anybody else says. Anyway, I have always understood it as the token being opaque for the verifier too, that only ever tested it for equality. The token that is opaque only for the holder is normally called "encrypted". It may not be opaque to the issuer, but that doesn't change much. But anyway, depending on what you read, you will get different meanings.
  - P5fRxh5kUvp2th 4y ago
    > Anyway, I have always understood it as the token being opaque for the verifier too Which falls flat on its face the second you realize the "verifier" can pull out information based upon that opaque token. It just means the intent is not for the person receiving it to do anything except reflect it back on subsequent requests. That's it. Typically it's done by handing something that is meaningless without context, said context not being available to the consumer being issued the token. But there is absolutely nothing that says you can't hand them a JWT meant to be used as an opaque token. If you're really worried about it, encrypt that bad boy before giving it to them.