Hi,
The F5 Oauth client handles key rotation by referencing the KID and it can be configured to check the keys endpoint at regular intervals for additional keys. I had this working with Okta however I’m into this bug listed here. I will raise a case with F5 as it looks like a standards compliance issue with there code. I am wanting to know if I can resolve this by modifying the auth0 configuration.
Currently I have configured the keys manually as a work around but if the keys get rotated it is going to break.
Okta just publish the kid, modulus and public exponent in there key endpoint. I’ve removed the X5T and X5C from the auth0 key to get it to parse on the F5 client as follows.
apm oauth jwk-config jwk_arcinfra.au.auth0.com_provider1 {
alg-type RS256
key-id REVGQ0QwOTJGMTA4MDBCNDlFQjI0NTAxREZGMzY1QzAwQ0E4REU5RA
modulus nGpHZs0DOWJkwcOq6LBJYh1IOSjT1t_9yL8SbrK0VkdLwlmSAxdNKT478-8yXnbclvJieIZwd-lEvbAeoUsEJbwZSM9BRyGtDp4nUN8HS1POFccdAwEr9zk_VAmZA42h5Zd8EsN82HTXL8CRJol9v-Z9FzRzqWRZW9EEnB9zEClTF8kiaYheMWxAqVl_5PYnFoUMjJV9OInrHFIe2Cy1t2mdwrTSh4rC7hhB9pD8BqrkY9Y01-ZT6-_Q-KtXSzLaqXhiWbRTGk56PsLKVAbSpl0-nYRHgfpBG97zGrs9NjmOoBnKcBjJzgssUicvvJ5R6Ebi-_S1_MTGF4NnHZA5Cw
public-exponent AQAB
shared-secret-enc-format none
}
This is what is comming from the endpoint by default.
“https://arcinfra.au.auth0.com/.well-known/jwks.json”
| alg | “RS256” |
|---|---|
| kty | “RSA” |
| use | “sig” |
| x5c | |
| 0 | “MIIDBTCCAe2gAwIBAgIJHA8VeLs33cB4MA0GCSqGSIb3DQEBCwUAMCAxHjAcBgNVBAMTFWFyY2luZnJhLmF1LmF1dGgwLmNvbTAeFw0xOTAzMjEwMzQ3MTdaFw0zMjExMjcwMzQ3MTdaMCAxHjAcBgNVBAMTFWFyY2luZnJhLmF1LmF1dGgwLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJxqR2bNAzliZMHDquiwSWIdSDko09bf/ci/Em6ytFZHS8JZkgMXTSk+O/PvMl523JbyYniGcHfpRL2wHqFLBCW8GUjPQUchrQ6eJ1DfB0tTzhXHHQMBK/c5P1QJmQONoeWXfBLDfNh01y/AkSaJfb/mfRc0c6lkWVvRBJwfcxApUxfJImmIXjFsQKlZf+T2JxaFDIyVfTiJ6xxSHtgstbdpncK00oeKwu4YQfaQ/Aaq5GPWNNfmU+vv0PirV0sy2ql4Ylm0UxpOej7CylQG0qZdPp2ER4H6QRve8xq7PTY5jqAZynAYyc4LLFInL7yeUehG4vv0tfzExheDZx2QOQsCAwEAAaNCMEAwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUvxKllUomKBVqx3C4npUHV1My/2gwDgYDVR0PAQH/BAQDAgKEMA0GCSqGSIb3DQEBCwUAA4IBAQBmnnIwgX9p9rN3YzREY98PPWgG/b3VDqgyXrchG94eaKn5KWbU6h8rEi/bWbVX6Yp5R/pMFjv9h/+gbISBY8hz+VC4cEtJdf83VbQo0y7V5LYYfuRad8stT9woN1GKwtB+yq1GGcEJ+ZUyvIrMK88hTTRRFaRgaEkJfLChuiku2Xn7l8QvrxNokyBT1G/04IeQ5sbtzl3G1mQL1nE9I+WoAelBHQzOsNUBFRuMNiaonlOvd/zVaAQccReYMn8UMn+Z0PYCEJq9gR+kEp8groRHvEg4ZmPahjI2kjudAqFlbb80Et+a/Ufd/L5TM4VEY1AASnm9ZpQqCn47Z+Gkfvmw” |
| n | “nGpHZs0DOWJkwcOq6LBJYh1IOSjT1t_9yL8SbrK0VkdLwlmSAxdNKT478-8yXnbclvJieIZwd-lEvbAeoUsEJbwZSM9BRyGtDp4nUN8HS1POFccdAwEr9zk_VAmZA42h5Zd8EsN82HTXL8CRJol9v-Z9FzRzqWRZW9EEnB9zEClTF8kiaYheMWxAqVl_5PYnFoUMjJV9OInrHFIe2Cy1t2mdwrTSh4rC7hhB9pD8BqrkY9Y01-ZT6-_Q-KtXSzLaqXhiWbRTGk56PsLKVAbSpl0-nYRHgfpBG97zGrs9NjmOoBnKcBjJzgssUicvvJ5R6Ebi-_S1_MTGF4NnHZA5Cw” |
| e | “AQAB” |
| kid | “REVGQ0QwOTJGMTA4MDBCNDlFQjI0NTAxREZGMzY1QzAwQ0E4REU5RA” |
| x5t | “REVGQ0QwOTJGMTA4MDBCNDlFQjI0NTAxREZGMzY1QzAwQ0E4REU5RA” |
This fails with the default Auth0 /.well-known/openid-configuration and /.well-known/jwks.json content.
The x5t value in /.well-known/jwks.json is correct but BIGIP fails to parse/handle it against the certificate content.
The reason it does this is because the BIGIP implementation is expecting the X5T value to include base64 padding characters (‘=’ characters) which MUST NOT be used in the context of JWS’s. This is why Auth0 does not have ‘=’ characters in KID/X5T; they conform to the RFC spec.
BIGIP JWKS consumption implementation needs a way in which to validate X5T without requiring padding characters to exist, e.g. calculate base64 KID/X5T and remove ‘=’ characters prior to comparison.