> > >> An ID Token using "alg":"none" sent over a TLS connect is fine, because > TLS makes it tamper-proof. > > >This not true. > > It guarantees delivery of the issued ID Token without changes from the OP > to the RP. >
Respectfully, FWIW, this is not true. TLS is a network-level protocol; modification before and after network termination but before application processing is definitely possible. It is not 'end-to-end' safe. I've had to deal with scenarios in production applications (e.g. application gateways, load balancers, etc) where a gateway implementation was changing HTTP headers and values after TLS termination before forwarding to an origin server. HTTP payload changes are possible as well, although rare. I've also seen this in hosted application server environments (e.g. Google Cloud Platform). This is why in certain stringent environments (e.g. Department of Defense, financial/banking, etc), I also disallow the b64 unencoded payload option because it 'passes the buck' to TLS which does not guarantee end-to-end security. Naturally, context is what is most important as to whether or not this TLS issue is sufficient or not for an application, but alg:none has always been problematic. IMO the alg:none option shouldn't have ever existed: if a JWT doesn't have an signature or key management algorithm, the alg parameter should be omitted entirely, making the concept of 'none' quite explicit rather than some existing-but-not-really parameter value. Kind regards, Les
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
