Dynamic Client Registration Step

1

Hello all,

I was reading through the Solid-OIDC primer and am having trouble understanding the difference between the registration listed there versus dynamic registration. Is the difference making a POST request with the client name and redirect_uri in a JSON object, or do I still perform a GET request but update client_id key with a static client_name instead?

Edit: I figured out how to do the POST request by the documentation, just took some trial and error. A better question is once I have received the information from the dynamic registration, do I resume the regular flow?

2

Hi @gaz009,

Yes, once you have completed dynamic client registration, you can go ahead and do whatever OpenID flow the client has been registered for (with the grant_types parameter). Typically, you’ll want to do the authentication code flow, and potentially the refresh flow.

Note that client credentials obtained via the dynamic client registration should be considered ephemeral: eventually, the OpenID Provider will get rid of them, as indicated in the registration response. The community servers happen not to expire client credentials, but that’s not an assumption you can make about all servers. In addition, each time the user logs out, when they log in the client will have a different set of credentials, which means the user will be taken to the consent prompt (where you have to approve the client) of the OpenID provider on each login. All this to say, if using a Solid-OIDC client ID document is an option, I would recommend doing so, as it will provide a more permanent identity to your client.

1 Like
3

Thanks for the response.

I managed to implement that so now it has the appropriate redirect. At this point I’m using dynamic registration since what I’m working with makes it a bit harder than usual to have accessible links. The application I’m working with is pretty much just an exercise with the authentication flow.

I’m guessing since I used the dynamic registration flow, I can skip step 7 and go straight to 9 since step 8 is by the OP server rather than the client app?

4

Can you link to the step-by-step guide so that I make sure I’m answering accurately :slight_smile: ?

5

https://solidproject.org/TR/oidc-primer#authorization-code-pkce-flow

I did figure it out, but I’ll respond so people who are also new to OIDC can get a grasp of what to do as well.

1 Like
6

I’m glad you figured it out.

But yeah to complete this thread for other’s sake, you are absolutely correct: in step 6, the client is sending its client identifier to the OpenID Provider. In the case of Dynamic Client Registration, there is no need for the OpenID Provider to look for additional client information, as it has been provided during the registration phase, which is why the OpenID Provider can move on to step 9. The browser is redirected to the client app on step 11.

The essential difference between Client ID in Solid-OIDC, Dynamic Client Registration and Static Client Registration is the way the OpenID Provider is given information about the client that is used as part of the security model of OpenID, in particular the redirect URL, the scopes and the grants the client has access to.

1 Like
7

Hi @gaz009
Are you using the CSS?
Could you please briefly describe the POST request used for dynamic client registration?
The endpoint used, parameters, etc.
Thanks in advance.
Stephen

1 Like
8

Hi @stephenbjm, this is more of a generic response but you’ll find a lot of information on the OpenID Connect Dynamic Client Registration specification, which the Community Solid Server complies with: Final: OpenID Connect Dynamic Client Registration 1.0 incorporating errata set 1. Looking at a deployed CSS instance, you can check out https://solid.redpencil.io/.well-known/openid-configuration for instance: their Dynamic Client Registration endpoint is at “https://solid.redpencil.io/.oidc/reg”, which means you’d send the POST request there, specifying at minimum your client’s redirect URL (all other client metadata is optional). The server response should contain your client credentials (id and secret), in addition to their expiration time.

9

Thanks @zwifi
Very useful. I got a client created on my local CSS instance. The POST request I made was against this endpoint (the CSS local instance endpoint): http://localhost:3000/.oidc/reg

The request had this JSON body:

{
“application_type”: “web”,
“redirect_uris”:
[“https://wwww.postman.com”]
}

A more complete example might be something like the following:

{
“application_type”: “web”,
“redirect_uris”:
[“https://wwww.postman.com”],
“client_name”: “My Example”,
“logo_uri”: “https://client.example.org/logo.png”,
“subject_type”: “public”,
“token_endpoint_auth_method”: “client_secret_basic”,
“jwks_uri”: “http://localhost:3000/.oidc/jwks”,
“userinfo_encrypted_response_alg”: “RSA1_5”,
“userinfo_encrypted_response_enc”: “A128CBC-HS256”,
“contacts”: [“ve7jtb@example.org”, “mary@example.org”]
}

10

If you are using Postman, you may be interested in https://communitysolidserver.github.io/CommunitySolidServer/6.x/usage/client-credentials/: Dynamic Client Credentials are suited to a in-browser client, but an app such as Postman is something that works quite well with Client Credentials.

11

Hello,
I am using Inrupt right now. For CSS, I am having issues configuring the endpoint with a self-signed certificate, as I am not using the Inrupt Solid libraries to support my development. I will be acquiring an actual CA-issued certificate hopefully soon for my testing, and will let you know if my current configuration works with CSS.