Summary of proposed feature
Provide access to the JWT header of the responding idToken from the OAuth provider in the profile() function.
Purpose of proposed feature
It's best practice to validate the contents of an idToken against public keys provided by the OAuth vendor (usually found at a .well-known endpoint provided by the vendor. Whilst this is possible due to the async nature of the profile() function, we currently do have access to the JWT header in said function (the first section of the 3 sections a JWT is made up of) which contains the following payload:
{
"alg": "HS256",
"type": "JWT",
"kid": "....",
}
We need access to the key ID above in order to validate the idToken validate the idToken against the .well-known endpoint provided by the OAuth vendor as they will rotate keys often and we need to be able to select the correct one that matches up with the kid we have received.
Detail about proposed feature
Provide another parameter on the profile() service that provides the header aswell as the payload and profile information. Furthermore, the ability to cache and retrieve the public keys on the Lambda would be preferable as public keys only tend to rotate every 3 months so wouldn't want to make an API call every time if it could be avoided.
Potential problems
None that I can tell.
Describe any alternatives you've considered
I've been told that there is work currently ongoing to customise request and response methods for providers with the ability to use async methods such as API calls which may negate this proposal entirely but I thought it best to leave the contributors to judge this.
Additional context
I don't feel I have the necessary skills to contribute on code with this one but happy to help.
Summary of proposed feature
Provide access to the JWT header of the responding
idTokenfrom the OAuth provider in theprofile()function.Purpose of proposed feature
It's best practice to validate the contents of an
idTokenagainst public keys provided by the OAuth vendor (usually found at a.well-knownendpoint provided by the vendor. Whilst this is possible due to the async nature of theprofile()function, we currently do have access to the JWT header in said function (the first section of the 3 sections a JWT is made up of) which contains the following payload:We need access to the key ID above in order to validate the
idTokenvalidate theidTokenagainst the.well-knownendpoint provided by the OAuth vendor as they will rotate keys often and we need to be able to select the correct one that matches up with thekidwe have received.Detail about proposed feature
Provide another parameter on the
profile()service that provides the header aswell as the payload and profile information. Furthermore, the ability to cache and retrieve the public keys on the Lambda would be preferable as public keys only tend to rotate every 3 months so wouldn't want to make an API call every time if it could be avoided.Potential problems
None that I can tell.
Describe any alternatives you've considered
I've been told that there is work currently ongoing to customise request and response methods for providers with the ability to use
asyncmethods such as API calls which may negate this proposal entirely but I thought it best to leave the contributors to judge this.Additional context
I don't feel I have the necessary skills to contribute on code with this one but happy to help.