Client Name Uniqueness and Registration Token Retrieving

This topic has 2 replies, 2 voices, and was last updated 4 weeks ago by Jatinder Singh (AcceptingNewProjects).

  • Author
    Posts
  • #28190
     ray.deng83
    Participant

    Two questions regarding Dynamic Client Registration here:

    1. Client Name Uniqueness. When registering a client through Dynamic Client Registration, AM doesn’t check the uniqueness of Client Name. I guess this is because AM will automatically generate a unique Client ID and use that as a reference. However, this might create some issue when the public agent doesn’t know if a client with the same name already exist and hence two Client IDs will be referring to the same the same client name. Do we have a way to enforce client name uniqueness in AM?

    2.Registration Token retrieving. The public agent doesn’t have a persistent storage to keep the registration token. Is there a way to retrieve the Registration Token when first time registering the client through Dynamic Client Registration? For example, using Client Id and Secret, which will be avaiable.

    Best,
    Le

    #28194
     ray.deng83
    Participant

    An additional question here:

    How do we update client secret through Dynamic Client Registration Management? When I send a request using Registration Token with a new password to update the client profile data, I received an error saying “Unable to update client secret”.

    #28220

    Howdy!

    I believe you are mixing the use of client_id with client_name. As per the spec, client_name is an optional parameter and is used for human-facing display, and doesn’t have to be unique. It’s the client_id that has to be unique. Client name is essentially metadata about a client and remains within the scope of a given Client Identifier. It can be any arbitrary string and supports i18n.

    Second Question:

    Registration Access Token is essentially a session token for a given Client Identifier provided it’s enabled. Think of it as a user session. If an already logged-in user attempt to login from an incognito window or a different User Agent, the user will be asked to re-login as there is no way to correlate or find which session a particular user belonged to. And that is why SSO_TOKEN_ID is sent back to AM in every post login call. Likewise if a Registration Access Token is not saved, there’s no way to retrieve that token afterwards. It’s a way for a given Client Identifier to authenticate in order to make any subsequent changes to its metadata.

    Hope this helps!

Viewing 3 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.

©2020 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?