OIDC dynamic client registration validity

[Wessel, Keith]

Thanks, Scott. I see a value in the json stored in the value column of the StorageRecords table for the secret expiration time, but I don't see anything stored in that JSON that seems to define a registration expire time. There's a value for when the client was registered, but not for when it expires. And the expires column of the StorageRecords table for everything with an oidcClientInformation scope is null, so it's not stored there, either. It's not at all clear to me how the IdP knows when these expire. But at least you've confirmed that the disappearing registrations have nothing to do with an expiration.

Keith


-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Cantor, Scott
Sent: Monday, February 28, 2022 7:50 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: OIDC dynamic client registration validity

>    1. When a client's registration is older than the 
> defaultRegistrationValidity, does the IdP remove it from the database?

The JPA storage back-end doesn't have any automatic purge of records. Anything past expiration is just invisible to the API.

>    2. Same question for the client secret validity period. What 
> happens when the client secret is older than the client secret validity time?

I think the way that works is to register a JWK URI rather than keys directly if you want to rotate them.

>    3. Can anyone suggest a reason why I'd have clients in my database 
> that have been there for months or years that haven't expired?

I guess it depends what the policy was when they registered, but it just stores the records with whatever expiration is set by the configuration, at least it does right now. Perhaps it was different in some way in the older versions.

>    4. Most importantly, how does a client "renew" their registration 
> or update the secret to keep their client from dropping out? Or do they simply need to re-register each time it expires?

I don't believe the spec defines an interoperable approach to that and a second attempt would probably return a different client_id. There's no protocol to really update what's there unless we invent something.

-- Scott


--
For Consortium Member technical support, see https://urldefense.com/v3/__https://shibboleth.atlassian.net/wiki/x/ZYEpPw__;!!DZ3fjg!t1QInh8DJabOgd_3jLEULiMzau1257y_X_803_VkTe4LrwnoM5dtFa8aLuJDDSPOYg$
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net