ID.5 listed as least depreciating. Mine was 55k new less than a year ago and it’s worth 30k. Definitely not the 10% mentioned in the article.
37 karma · joined February 16, 2015
Example: The fact that my service has an http stack which must parse a cookie header doesn't mean my app must accept its contents as valid. There's a lot of confusion on this thread about which components should/must do what things.
If you issue tokens with none, then you will have to accept them when clients send them back. This is obviously a very bad idea, but that's all th spec says. If the issuer chooses to be insecure, that is a valid choice.
If you issue tokens with a specific algo, and clients send them back with a different or none header, you know they have been forged.
The spec allows issuers to decide whether to use none, it doesn't say you must trust none tokens if you know you didn't issue them.
Why would an issuer ever let a client decide what algo to use?
"Send a header that specifies the "HS256" algorithm when the application normally signs messages with an RSA public key."
Again, under what circumstances would a header be used by the client to ask for a specific implementation?
What about encrypted client side cookies - would you let the client "send a header" to specify which key to use???
The only problems you highlighted are serious input validation issues and a naive, broken trust model.