3 ms·
The only case I've come across so far of needing the unverified claims is when you need to verify the signature based on a key dependent on the token issuer (is
by jimktrains2 6y ago
The only case I've come across so far of needing the unverified claims is when you need to verify the signature based on a key dependent on the token issuer (iss claim).
You could arguably define another means of out-of-band signalling, though, but it would also be unauthenticated.
Edit: That said, getting the unauthenticated data should be very explicit and impossible to do "accidentally", if the library allows it at all.
- hinkley 6y agoI'm not terribly familiar with the implementation details here. Are you essentially talking about having different strategies to verify the token? Would it make sense to provide some sort of filter function as a parameter that the library can call to clarify what operations need to be performed? That would allow you to peek at the records in a context where your role is clear, and where the code flow makes it awkward to take the data and run with it. If the code feels wrong enough, it's hard for the developer to claim ignorance, and if it's clear from the outset that ignorance is not an explanation, that leaves malice and stupidity. Most developers won't admit to either, but if forced they'd rather be seen as malicious than stupid, and malicious gets you a meeting with HR.
- jimktrains2 6y agoYes, some libraries provide a key callback function where the unauthenticated token is provided for this type of thing, but the result of the function is supposed to be the key used to verify the token and nothing else is supposed to happen as a side effect.
- hinkley 6y agoOh good, that's what I hoped. Yes, you could have side effects, but it's pretty damned obvious you're being naughty. That's mostly what I want. The obviousness of the cheating makes people think twice, ask questions. Slow down.