Custom names for TOTP Authenticators

[jamescottrill]

Custom names for TOTP Authenticators

Problem

Users can have multiple TOTP Authenticators registered with FusionAuth. If they lose one or change devices, they will want to remove that authenticator from their account. Currently it's impossible to tell which of your authenticators is which device.

Solution

Users will be able to add a custom name/identifier to their Authenticator, to differentiate between apps/hardware keys etc.

Related Issues

• https://github.com/FusionAuth/fusionauth-issues/issues/1463

Alternatives/workarounds

Using a self-hosted flow, users could add this field and we would store it in a database alongside the id and join in the front end (although this is not currently returned when a 2FA method is added), so adds additional complexity. This would also require complete ownership of the login flow, to capture changes when 2FA is enforced and set on login, which is a significant undertaking.

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.

[mooreds]

@jamescottrill is this a duplicate of https://github.com/FusionAuth/fusionauth-issues/issues/1463 ? Seems so on first read. If so, please upvote 1463 and close out this issue. If not, no worries!

[mooreds]

Actually, I take that back. It's slightly different, so I think we should leave it open.

[robotdan]

Internal: Currently this is just a string to uniquely identify the authenticator method amongst others. From the API side, it should be fairly straight forward to take this value on the API as optional, and generate it like we do today if not provided.

We would likely just want to limit the length to something reasonable since it will be stored on the user.

Separately we'd need to update the admin UI, self-service account pages, and optionally the login workflow that allows the user to enable 2FA during login to accept this optional.

We'd also want to let the user modify this value via API, or via self-service account pages.