Implement JWT structure and logic for ID token in the provider mock #162
Conversation
I'm missing the context here. Why do we implement JWT logic now? |
s/decripting/decrypting |
Because this is the format used by OIDC to validate and safeguard the ID tokens. We used to ignore it to make our life easier when creating the mock tokens, but it's better to have our code closer to reality. |
We used to ignore the JWT format in the tests, so we could manually
write the ID Token. Now that we decided to implement the JWT logic
also, the ID token structure becomes more complex:
{header}.{payload}.{signature_string}
To avoid generating all of this manually, it's better to switch to a
package that already handles this parsing with the right encryption and
encoding.
This is one of the key (pun intended) endpoints of an OIDC provider. It returns the required keys for decrypting some of the payloads. We only care about the JWK needed to decrypt the tokens, so it only returns that one.
Now that the mock respects the JWT format and safety, we no longer need this option in the tests, so it should be removed.
denisonbarbosa
force-pushed
the
mock-jwt
branch
from
2660131 to
844f3b2
Compare
This implements the
/keyendpoint for the provider and also reworks the ID token generation in the tests to resemble the "real" ones. By doing this, we are better covered in our tests. More detailed explanations can be seen in the commit messages.UDENG-3724