2.2 KiB
Cisco: Org Level OAuth2 Clients
- tags
- cisco
- source
Org Level Clients
Goal: When the creator of an OAuth2 client leaves the company. we wish to keep the client working while disabling the user.
Technical Solution
We should provide a field that marks a client as being owned by the org and not by a particular user.
What does this mean:
- Every admin of the org should be able to see and edit the client
- During the creation of the client we should add an option such that we know this client is an org-level client
Looking at the code, it means that we should just change the
iroh-auth.oauth2-client-service.core/accessible-for?
function.
We should probably add a new optional field to ease both the creation and the search for org-level clients.
I propose to add an optional org-level?
field.
If true during the creation then we should set the owner-id
to be equal to
the org-id
.
Security concerns
While not mandatory, handling an ownership change should mean we would like to provide a way to change the client's secret. So we should provide a Client Secret Reset mechanism. Probably a single POST endpoint that would generate a new password. And as we would not want to break the clients during a password change, the client should probably support two passwords temporarily. So having a configurable by the user grace period during which the old password will still be accepted.
So it means adding the following optional fields to the client object:
old-password
: the old password on password changeold-password-valid-until
: the date after which the old password will be rejected.
The time during which two passwords could be accepted could last up to a few weeks.
Tasks
-
Support org-level client:
- add an
org-level?
boolean field. If this field is true then the client must not have anyowner-id
field. - org-level clients should be visible to all admins, for reading and searching
- we should provide a new route to promote normal clients to org-level clients.
- add an
- OPTIONAL Support client-secret reset