Pluggable Token Handling

[esatterwhite]

Particularly in the case of opaque tokens, It would be great to be able to include the token management as a part of the adapter or some other swappable mechanism. We have a system for managing tokens, and we don't wish to change that. In utilizing this library, it doesn't seem there is a way to define a new token type or control how one is generated.

Ideally, this library should allow implementers to define how a token format is defined and managed.

[panva]

Please extend your thought considerably, as is there isn't enough to go off of. As per https://github.com/panva/node-oidc-provider/discussions/new?category=ideas

Only fully-fledged ideas with description, examples and clearly stated "why" or "what for" stand a chance of being discussed, otherwise they will be closed and eventually removed.

[esatterwhite]

At the same time I'd think of a MAC digest of the prefix and value as part of the issued opaque value.

We have a bit of both. We have an identifiable prefix of different token types, we HMAC either a random value, or some user supplied key, and include a crc33 hash. Then keep a checksum so the public tokens are never actually persisted. Which is important for various compliance reasons at our company.
This, in addition to a tiered and mailable acl system.

There are quite a number of reasons to be in control of the management of the tokens themselves.

[esatterwhite]

What else would be needed for this to become a concrete feature?

[weyert]

Looks like a nice idea!

[esatterwhite]

@panva just checking back here. What would it take to push this forward?

[panva]

@esatterwhite I'm open to having the issued opaque tokens and cookie values have a CRC checksum and a fixed prefix. That alone is a feature I would get behind. Having this "pluggable" like so I am not interested in pursuing.