Add Support For JSON Web Tokens (JWT)

[thomaskonrad]

Hi,

it would be nice if the extension would be able to detect JSON Web Tokens (JWT) as well, as they are also frequently used for single sign-on. Such a token consists of the Base64URL-encoded chunks separated by two dots, for example:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Note that the = signs that are used for padding are stripped away at the end of each Base64 chunk and re-added just before the token is decoded. Also, + signs are replaced by - signs and / is replaced by _ (that's what Base64URL encoding does). Look at this JWT implementation at lines 29 and 44 to see an example. I'm explaining this because I thought it could make a difference when trying to detect such tokens in HTTP traffic.

Cheers
Thomas

[thomaskonrad]

I came up with a RegEx that matches these tokens:

[a-zA-Z0-9-_]{19,}\.[a-zA-Z0-9-_]{3,}\.[a-zA-Z0-9-_]{0,}

Explanation: a-zA-Z0-9-_ is the alphabet of Base64URL encoding. The reason for the minimum length of 19 for the first part is that at least the algorithm has to be specified in the header (first chunk). As all currently supported algorithms have a length of 5 letters, a header with the minimum length would look like this: {"alg":"none"} which is eyJhbGciOiJub25lIn0 in Base64URL. The shortest possible JSON object for the second part would be {}, which gives e30. And the third part can be empty, which is the case when using{"alg":"none"}.

[CheariX]

Hi,

we have already "tried" to implement this.
The main Problem here ist, that - in OpenID Connect - the id_token is transfered in the HashTag of a URL in a HTTP Response.
AFAIK it is not that easy possible to access the HTTP Responses.

However, we implemented this, but up to know, it lead to other Bugs (SAML XSW no longer working) and we hadn't time to fix and merge it.