Uploaded image for project: 'OpenAM'
  1. OpenAM
  2. OPENAM-10481

Default JWKS_URI of an OpenID provider doesn't allow signing key rotation

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 13.5.0, 14.0.0
    • Fix Version/s: None
    • Component/s: oauth2, OpenID Connect
    • Labels:
    • Support Ticket IDs:

      Description


      This issue is about key rotation of the provider JWKs. So its only concerning rotating the AM signing keys. For doing a rotation of the encrypted keys used by AM, you can do it today with AM: for encrypting, AM is using the public key from the client JWKS URI. It's then up to the client to rotate the keys and AM will automatically pick up the new public key to use.

      Description

      To allow key rotation, AM needs to offer:

      • a way to switch the key used for signing
      • generate a JWKS URI that contains the public keys currently used for signing and also the old signing key for a limited period of time

      AM nearly offers all those possibilities:

      • You can change the signing key used by changing the key alias in 'Token Signing RSA public/private key pair' and/or 'Token Signing ECDSA public/private key pair alias'
      • AM will automatically pick up the changes and generate a jwk_uri from those two fields.

      However, AM doesn't offer the possibility to set a retention delay for the old keys, as suggested in the openid standard: http://openid.net/specs/openid-connect-core-1_0.html#RotateSigKeys

      The JWK Set document at the jwks_uri SHOULD retain recently decommissioned signing keys for a reasonable period of time to facilitate a smooth transition.

      How to reproduce

      Expected

      The JWK corresponding to the key you removed|replaced is still there. This key should be removed after a reasonable period of time as describe in the standard.

      Actual

      The JWK corresponding to the key you removed|replaced has been removed from the JWKS_URI content.

      Consequences

      It means that id token generated just before you changed the key will become invalid. You will get a pick of invalid tokens just after the key rotation, that will decrease over the time.

      Workaround

      Solution 1

      The client can cache the JWKs from AM for a certain period of time. It will prevent rejecting an old valid token generated with the old key if we actually have the right JWK in cache.

      However, it doesn't prevent an old valid token to be rejected by a third party that doesn't cache the JWKS or never actually load this JWK before. They should be odd cases.

      Solution 2

      OpenAM offers a possibility to implement your own JWKS for the AM provider JWKs. For that, you will need to be able to generate the JWKs from the AM keystore.
      This solution is currently not possible until OPENAM-10478 is not fixed.

      Solution 3

      If you have read the consequences section, you may be able to live with a pick of invalid token, especially if you plan the key rotation to happen on off-pick time. If you are a company using AM to manage your employees, perhaps doing it every day at 1 am would be acceptable.
      This solution has the advantage that as soon as this Jira is fixes and you migrate to a correct version, this invalid token pick will disappeared.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                quentin.castel Quentin CASTEL [X] (Inactive)
              • Votes:
                2 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                • Created:
                  Updated: