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

Dynamic OIDC Client Registration with extra attributes customizable



    • Type: Improvement
    • Status: Open
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: OpenID Connect
    • Labels:
    • Support Ticket IDs:



      Currently some of the OAuth2/OIDC attributes like token/jwt lifetime only takes in the default settings. Although this is passed in the values is not set and is alway 0 (default).

      How to reproduce the issue

      -1. Setup OIDC provider for the realm

      -2. Enable dynamic client registration for the realm

      -3. Send a client registartion like in  http://openid.net/specs/openid-connect-registration-1_0.html#ClientRegistration"

      Say some extra attributes:

         "access_token_lifetime": 3600,
         "jwt_token_lifetime": 43200,

      Expected enhancement

      Desirable if there is a way to be able to extend this to have certain client able to have cert defaults (say lifetime). So the enhancement is to have some what to extend this to have certain client setting

      Current behaviour

      All undefined attributes in hte OIDC specs will use the defaults in the provider settings (if they  are passed and if this can be case-by-case set). Eg: "client_secret_expires_at":0,"access_token_lifetime":0,"refresh_token_lifetime":0 or jwt_token_lifetime:0

      Work around

      Only defaults client settings. No logic in doing customization

      Code analysis

      createRegistration does parse in all the passed in OIDC setying attributes but org/forgerock/openidconnect/ClientDAO.java only maps things it need to the internal names (so others are left default).


      Sure time like "client_secret_expires_at":0,"access_token_lifetime":0,"refresh_token_lifetime":0 or jwt_token_lifetime:0  may not be good to change (as what's passed in by client) but if there is an extension to have these values take into account as constraints and maybe customizable logic, this may help

      So at this point it seem the old OAuth2/OIDC admin endpoint is still needed to do this.




            • Assignee:
              chee-weng.chea C-Weng C
            • Votes:
              1 Vote for this issue
              6 Start watching this issue


              • Created: