I was reading this question How to verify that the idToken is valid and watching this vídeo https://www.youtube.com/watch?v=M4JIvUIE17c and I got me wondering… Why id token is an JWT if it’s meant to be used by the client. Why not a simpler JSON is send back after login? The client will have to parse and encode jwt to have user informations, but if I understand correctly it doesn’t need to be validated as in most cases the client application is registered into auth server and login is done in a auth server environment, and even in a case of a refresh, is commom to use a another refresh token… So I can’t see the point to use a JWT.
Can someone tell me why this was chosen as standard for protocol
2
Answers
Some of the benefits with a JWT are:
Having a JWT instead of a plain JSON String has many advantages. As a base64 encoded string, it is easier to include in the query string or added as a response header for example.
Any serious client application should validate the token signature before trusting it.
By having a standard format, we get much better interoperability between platforms, services, and languages.
Before using id token, the party has to verify it. Reference: https://openid.net/specs/openid-connect-core-1_0.html#ImplicitIDTValidation
To verify the token, the token itself has to be in SOME format – it has to follow some specs so the client can actually process it. The authors of OIDC could pick anything – plain json, comma separates string, etc – but they would have to describe how to process it correctly.
JWT happened to be a perfect fit for this task – a format which is well understood and many libraries already know how to deal with it. Hence the authors of OIDC decided to use it.