On Wed, Sep 18, 2019 at 4:24 PM Dick Hardt <dick.ha...@gmail.com> wrote: > > What happens if the access token is lost or compromised? Does the app need to > be completely re-registered?
Yes. Re-registration breaks many things though, so it's often not an option. In these cases, the client is pretty much stuck with only bad choices :-/ The token lifecycle of DCR(M) is one of the areas that would be great to improve IMO. We originally had planned to always issue a dynamic client a secret that it could use to get a DCRM scoped token using the CC flow. We opted not to do that in the end because the client could be using certs, for example, and a secret for management would lower the security of the client. Using the credential (like a signed JWT using an asymmetric key as you mention, Dick) could be a good way to handle this. Perhaps RFC 7592 (DCRM) should be updated with some info about allowing the client to use the CC flow with whatever credential it registers with, just for the purpose of obtaining a new DCRM-scoped registration management token. Justin mentioned this though: > Why not use the client’s credentials? Because not all clients are set up to > have credentials, plus we’d be spreading the requirement to support different > kinds of client credentials to another endpoint. IMO, the dynamic client should go to the token endpoint with whatever credential it registered with using the CC flow and a scope of "dcrm". So, the last concern about spreading the need to authenticate to other endpoints would be moot. I'm not sure what to say about public clients. ATM, in our product at least, we don't support public clients registering, so this wouldn't pose an issue for us. Could for others I suppose. Short of CC though, I can't think of a good way to get a new registration management token. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
