Edit history

Summary

SSO provisioned users (especially in instances where SSO is required) can do a bunch of actions they shouldn't be able to do such as:

• Changing their email.
• Setting or changing their password.
• Configuring authentication methods like passkeys and authenticator apps.
• Deleting their own account.

These are all things that should be managed by the external IdP. Even though nothing is broken it can be considered a bug due to the fact SSO is meant to take away account management per service like this. Even though a user still logs in with their external IdP with the same email and password, these features being available can cause a lot of user confusion. In the case of account deletion, it even gets rid of the SSO link so users can circumvent bans or punishment, or impersonate as new people. As for deleting. The SSO link is lost upon delete, meaning users can abuse it to make new profiles via the same account and any information about who this user is to for example ban them on other associated services is gone. The SSO link should remain even when deleted so new accounts cannot be made via the same account on the external IdP. But ideally, in my opinion, deleting shouldn't be possible inside Fluxer and is instead the responsibility of the external IdP. This is a much more strict version of SSO, especially useful in corporate settings, so it would be a good idea to make it a boolean option in the instance settings for SSO. Sort of derived from #696 but feels like it should be its own item.

Steps to reproduce

1. Set up a Fluxer instance.
2. Enable SSO login.
3. Create an account through the SSO flow.
4. Login and go to Account settings.
5. Try to execute any of the actions listed above.

Environment

Stable Web 2026.702.163118, Linux (x86), Chrome 149.0.0.0, Locale en-US

Summary

SSO provisioned users (especially in instances where SSO is required) can do a bunch of actions they shouldn't be able to do such as:

• Changing their email.
• Setting or changing their password.
• Configuring authentication methods like passkeys and authenticator apps.
• Deleting their own account.

These are all things that should be managed by the external IdP. Even though nothing is broken it can be considered a bug due to the fact SSO is meant to take away account management per service like this. Even though a user still logs in with their external IdP with the same email and password, these features being available can cause a lot of user confusion. In the case of account deletion, it even gets rid of the SSO link so users can circumvent bans or punishment, or impersonate as new people. As for deleting. The SSO link is lost upon delete, meaning users can abuse it to make new profiles via the same account and any information about who this user is to for example ban them on other associated services is gone. The SSO link should remain even when deleted so new accounts cannot be made via the same account on the external IdP. But ideally, in my opinion, deleting shouldn't be possible inside Fluxer and is instead the responsibility of the external IdP. This is a much more strict version of SSO, especially useful in corporate settings, so it would be a good idea to make it a boolean option in the instance settings for SSO. Sort of derived from #696 but feels like it should be its own item.

Steps to reproduce

1. Set up a Fluxer instance.
2. Enable SSO login.
3. Create an account through the SSO flow.
4. Login and go to Account settings.
5. Try to execute any of the actions listed above.

Environment

Stable Web 2026.702.163118, Linux (x86), Chrome 149.0.0.0, Locale en-US

Logs or screenshots

No response

Checks

• ☑ I searched existing issues.
• ☑ I wrote this report in my own words, except for direct translation if needed.

Summary

SSO provisioned users (especially in instances where SSO is required) can do a bunch of actions they shouldn't be able to do such as:

• Changing their email.
• Setting or changing their password.
• Configuring authentication methods like passkeys and authenticator apps.
• Deleting their own account.

These are all things that should be managed by the external IdP. Even though nothing is broken it can be considered a bug due to the fact SSO is meant to take away account management per service like this. Even though a user still logs in with their external IdP with the same email and password, these features being available can cause a lot of user confusion. In the case of account deletion, it even gets rid of the SSO link so users can circumvent bans or punishment, or impersonate as new people. As for deleting. The SSO link is lost upon delete, meaning users can abuse it to make new profiles via the same account and any information about who this user is to for example ban them on other associated services is gone. The SSO link should remain even when deleted so new accounts cannot be made via the same account on the external IdP. But ideally, in my opinion, deleting shouldn't be possible inside Fluxer and is instead the responsibility of the external IdP. This is a much more strict version of SSO, especially useful in corporate settings, so it would be a good idea to make it a boolean option in the instance settings for SSO. Sort of derived from #1254 but feels like it should be its own item.

Steps to reproduce

1. Set up a Fluxer instance.
2. Enable SSO login.
3. Create an account through the SSO flow.
4. Login and go to Account settings.
5. Try to execute any of the actions listed above.

Environment

Stable Web 2026.702.163118, Linux (x86), Chrome 149.0.0.0, Locale en-US

Logs or screenshots

No response

Checks

• ☑ I searched existing issues.
• ☑ I wrote this report in my own words, except for direct translation if needed.