JWT issuer check does not account for encrypted JWTs

[zandbelt]

The changes in 43a03ab do not seem to account for encrypted JWTs where the id_token iss value can only be checked after decrypting the token. Rather than:

1. do basic claim checks
2. verify id_token"

the process should be changed to:

1. decrypt id_token
2. do basic claim checks
3. verify id_token signature

I believe that in its turn calls for splitting the from_jwt method on the IdToken class into separate decryption and verification methods.

The alternative is to rollback this change...

[panva]

Didn't familiarize myself with the changes but an operation where iss, aud and other claims are replicated into the unencrypted part of the JWT in order to support the required operation should be taken into account and processed accordingly.

https://tools.ietf.org/html/rfc7519#section-5.3

In some applications using encrypted JWTs, it is useful to have an
unencrypted representation of some claims. This might be used, for
instance, in application processing rules to determine whether and
how to process the JWT before it is decrypted.

This specification allows claims present in the JWT Claims Set to be
replicated as Header Parameters in a JWT that is a JWE, as needed by
the application. If such replicated claims are present, the
application receiving them SHOULD verify that their values are
identical, unless the application defines other specific processing
rules for these claims. It is the responsibility of the application
to ensure that only claims that are safe to be transmitted in an
unencrypted manner are replicated as Header Parameter values in the
JWT.

Section 10.4.1 of this specification registers the "iss" (issuer),
"sub" (subject), and "aud" (audience) Header Parameter names for the
purpose of providing unencrypted replicas of these claims in
encrypted JWTs for applications that need them. Other specifications
MAY similarly register other names that are registered Claim Names as
Header Parameter names, as needed.

[zandbelt]

Fair point: the process would then become:

1. check if the JWT header contains basic claims and validate those
2. decrypt id_token
3. verify basic claims if not done already via claims in the header
4. verify signature

[panva]

2.5 verify claims present in both the unencrypted header and encrypted payload are the same ;)