fusionauth-issues icon indicating copy to clipboard operation
fusionauth-issues copied to clipboard

Disable sign in to applications without having to delete the application

Open einal3m opened this issue 3 years ago • 3 comments

Allow updates to inactive users and applications

Problem

We sync our companies customer accounts and their employees into FusionAuth applications and users. When a customer account churns or an employee leaves, we will mark them as inactive. However, customer accounts and employees may return and be reactivated. During the time they are inactive, changes may be made to their data. Data that we'd like to be kept in sync within FusionAuth (most likely in the data field), so that when they return, their data is up to date. Also, for employees, a common case is that they may be stripped of their emails after they're deactivated, so the email can be given to someone else. (regularly happens when our customers have hired contractors and they reuse emails)

Solution

We'd love it if we could update users and applications (using the PATCH /api/application/{id} and PATCH /api/user/{id} endpoints)

Alternatives/workarounds

We've considered activating the application/user, updating them, then deactivating them. This would work, but there is a risk that if something went wrong with the update, then we may have a user or a customer account that is left active and they are able to sign in.

Additional context

Add any other context or screenshots about the feature request here.

Community guidelines

All issues filed in this repository must abide by the FusionAuth community guidelines.

How to vote

Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.

einal3m avatar Aug 05 '22 07:08 einal3m

Another alternative/workaround is to do a full sync of data (from your system to the data field) whenever a user or application is returned and reactivated.

What are your thoughts on that approach?

mooreds avatar Aug 05 '22 11:08 mooreds

Yeah, I have thought about that, but it's not really available to us as we are syncing our users/applications using an event sourced feed.

I've also realised that deactivating a user is actually a delete api call... so I understand now why you would not allow updates to a "deleted" record.

Josh has suggested looking into user actions to prevent users from being able to log in, rather than deactivating them. Also to investigate using the user.login.success webhook to check fields in data and make a decision there whether or not to allow the user to successfully sign in.

einal3m avatar Aug 09 '22 01:08 einal3m

For users there seems to be a few options to prevent them from signing in, user.expiry and user actions. Turns out, these methods will actually work better for us than deactivating them ⭐

For applications however, we're not going to be able to deactivate an application when one of our customers churns. For now we'll store our customers status in data and do some manual intervention ourselves.

I'll change the title of the issue to reflect that our issue now is just with our inability to easily disable sign in for applications without deleting the application.

einal3m avatar Aug 25 '22 01:08 einal3m