Subject: [OAUTH-WG] Dynamic Client Registration - client_secret_expires_at

From: Filip Skokan <[email-masked]>
Date: Tue, 20 Nov 2018 12:44:50 +0100

Hi all,

a recent query about expiring client credentials (secrets) got me thinking
about client_secret_expires_at client metadata from RFC 7591 used also in
7592 as well as OpenID Connect Dynamic Client Registration 1.0

*What does expired client secret (in the sense of client_secret_expires_at
with a non 0 value) mean beyond obviously not processing secret-based
client authentication (basic, post and client_secret_jwt) after the given
timestamp?* *Fingers Crossed* I'm hoping for your comments and experience
from existing deployments on the topic to shed some light on this for me
and maybe others too. Also that this doesn't get lost between the current
BCP/implicit discussions.

This is my best shot at an implementable policy when it comes to clients
with expired client secrets: *"all operations requiring a secret will be
rejected when an expired one is presented"*

   - it is not valid for client secret based endpoint auth (basic, post,
   client secret jwt), the AS will reject with 401 invalid_client in those
   cases
   - it will not be used for validating symmetrically signed request object
   (JAR), the AS will reject the authorization request with ...?
   - it will not be used by the AS to symmetrically sign id tokens,
   userinfo, introspection or authorization responses (JARM), the AS will
   reject the requests with ...?
   - anything else?

I feel this is reasonable interpretation and if so, are there appropriate
errors to return to clients (both front and back-channel) when an expired
secret is encountered during one of the operations that need it?

Thank you very much for your thoughts and comments.

Best,
Filip

---

From: Travis Spencer <[email-masked]>
Date: Fri, 30 Nov 2018 20:44:48 +0100

> rejected when an expired one is presented"*

This is a good list and hopefully something that would find its way into a
spec and not be buried in an email archive. With this info, its a lot
easier to make use of this feature of the spec. Thanks for sharing it,
Filip.

it is not valid for client secret based endpoint auth (basic, post, client
> secret jwt), the AS will reject with 401 invalid_client in those cases
>

Or instead of invalid_client, need_info.

it will not be used for validating symmetrically signed request object
> (JAR), the AS will reject the authorization request with ...?

400 invalid_request_object

it will not be used by the AS to symmetrically sign id tokens, userinfo,
> introspection or authorization responses (JARM), the AS will reject the
> requests with ...?
>

403 need_info.

In the case of introspection, a client secret can't be used to sign the JWT
if application/jwt was requested because access will be denied will be
denied before that point. So, that's 401 (first point above)

anything else?

Revoke -- 401