Draft: Make 2FA management more flexible
What does this MR do?
Related to #17019
This makes 2FA management more flexible by allowing a user to change OTP/authenticator applications without completely disabling 2FA. This allows the user to retain existing U2F and WebAuthn devices.
The intent is also to not require the user to regenerate recovery codes. However, this iteration still regenerates and displays new recovery codes to the user each time the application is changed. As a follow-up we can more intelligently detect whether this is first time 2FA enablement or just registering a new OTP application. If the latter, we don't need to regenerate codes.
This implementation differs slightly from the designs in the issue for a couple of reasons:
- The designs are more than 2 years old and the GitLab design has evolved a lot.
- In some cases the text was not the clearest (It's probably still not ideal. I'm open to improvements!)
- As a follow-up to this issue we will be making more changes to the user profiles in #215408.
Screenshots
Current
Proposed
Does this MR meet the acceptance criteria?
Conformity
-
Changelog entry -
Documentation (if required) -
Code review guidelines -
Merge request performance guidelines -
Style guides -
Database guides -
Separation of EE specific content
Availability and Testing
-
Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process. -
Tested in all supported browsers -
Informed Infrastructure department of a default or new setting change, if applicable per definition of done
Security
If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:
-
Label as security and @ mention @gitlab-com/gl-security/appsec -
The MR includes necessary changes to maintain consistency between UI, API, email, or other methods -
Security reports checked/validated by a reviewer from the AppSec team