Thanks Peter!
Note, just to clarify for readers:
the use case for this is to de-provision users outside of the interactive user logins (i.e. when you need to check if a user exists and is valid but the user is not actively browsing your web site).
Some answers in no particular order:
-
[1] The vendor agnostic alternative that we were thinking about so far is to expose a CIS API, but this is not on the todo list for now (so I added an issue at least), though PRs are welcome of course
Would be quite nice though! -
Auth0 hooks: there isn’t the hook we want out of the box yet, though we could draft a rule that triggers a webhook as well. I’d be surprised if Auth0 does not eventually support this out of the box though as there are already similar hooks being added.
-
[2] We do have a backlog item for self-servicing client_id+secret requests (which I’d love to have already!), but I do not think we will have this for management API requests as this exposes more data, attack surface, has a strong vendor lock-in, we cannot verify that your session checks work remotely, etc. This is for cases where it makes sense basically, which so far there are 3 of (out of about ±80 clients). In order words these are actually exceptions and handled as such which I believe is fine. Note that if we ever get to work on [1] you would get the access by default and would not need request, which would be the best of both worlds
Guillaume
[1] https://github.com/mozilla-iam/iam-project-backlog/issues/174
[2] https://github.com/mozilla-iam/iam-project-backlog/issues/111
