[GH-ISSUE #3254] Android: Passkeys don't work with Mastodon #7911

Closed
opened 2026-04-11 00:39:49 -05:00 by GiteaMirror · 6 comments
Owner

Originally created by @kyrias on GitHub (May 18, 2024).
Original GitHub issue: https://github.com/bitwarden/android/issues/3254

Steps To Reproduce

  1. Go to a Mastodon instance (e.g. https://mastodon.world/)
  2. Click log in
  3. Fill in e-mail and password
  4. Click on 'LOG IN'
  5. Click on 'USE SECURITY KEY'

or

  1. Go to a Mastodon instance where you're already logged in
  2. Go to Settings -> Account -> Two-factor Auth
  3. Click on 'Edit' next to 'Security keys'
  4. Type some name into the nickname field
  5. Click on 'ADD NEW SECURITY KEY'

Expected Result

You're asked to either select a Bitwarden pass key, or to save a new passkey in Bitwarden.

Actual Result

It just offers the standard Google passkey implementation options.

Screenshots or Videos

No response

Additional Context

Using passkeys with Bitwarden works through the same Mastodon frontend on desktop Chrome with the Bitwarden extension.

Using passkeys with the Android Bitwarden app works on other websites through Chrome for Android.

Operating System

Android

Operating System Version

14

Device

Pixel 8a

Build Version

2024.4.1 (10283)

Beta

  • Using a pre-release version of the application.
Originally created by @kyrias on GitHub (May 18, 2024). Original GitHub issue: https://github.com/bitwarden/android/issues/3254 ### Steps To Reproduce 1. Go to a Mastodon instance (e.g. https://mastodon.world/) 2. Click log in 3. Fill in e-mail and password 4. Click on 'LOG IN' 5. Click on 'USE SECURITY KEY' or 1. Go to a Mastodon instance where you're already logged in 2. Go to Settings -> Account -> Two-factor Auth 3. Click on 'Edit' next to 'Security keys' 4. Type some name into the nickname field 5. Click on 'ADD NEW SECURITY KEY' ### Expected Result You're asked to either select a Bitwarden pass key, or to save a new passkey in Bitwarden. ### Actual Result It just offers the standard Google passkey implementation options. ### Screenshots or Videos _No response_ ### Additional Context Using passkeys with Bitwarden works through the same Mastodon frontend on desktop Chrome with the Bitwarden extension. Using passkeys with the Android Bitwarden app works on other websites through Chrome for Android. ### Operating System Android ### Operating System Version 14 ### Device Pixel 8a ### Build Version 2024.4.1 (10283) ### Beta - [X] Using a pre-release version of the application.
GiteaMirror added the bug label 2026-04-11 00:39:49 -05:00
Author
Owner

@kyrias commented on GitHub (May 18, 2024):

I'd be happy to try whatever necessary to help debug this and provide whatever additional details are necessary. I tried looking at what Mastodon passes to navigator.credentials.create/.get but couldn't really see anything that stood out to me as particularly strange.

<!-- gh-comment-id:2118806136 --> @kyrias commented on GitHub (May 18, 2024): I'd be happy to try whatever necessary to help debug this and provide whatever additional details are necessary. I tried looking at what Mastodon passes to `navigator.credentials.create`/`.get` but couldn't really see anything that stood out to me as particularly strange.
Author
Owner

@kyrias commented on GitHub (May 18, 2024):

Ah, investigating some more it seems like the mobile app only supports using passkeys when requireResidentKey is true, whereas the browser extension doesn't have that limitation.

<!-- gh-comment-id:2118987683 --> @kyrias commented on GitHub (May 18, 2024): Ah, investigating some more it seems like the mobile app only supports using passkeys when `requireResidentKey` is `true`, whereas the browser extension doesn't have that limitation.
Author
Owner

@SergeantConfused commented on GitHub (May 21, 2024):

Hi @kyrias,

Thank you for this report. Yes, Android would not allow intercepting and storing a new passkey when requireResidentKey is true; However, you should be able to use such a passkey from inside your individual Bitwarden account to log in on mobile, assuming you initially saved it via the browser extension. With regard to the fact that Bitwarden is not being shown as an option when attempting to pass the 2FA stage, that's expected as outlined in the warning in the documentation.

I will now proceed and close this GitHub report; Please feel free to get in touch if you have any questions or concerns.

Thank you again,

<!-- gh-comment-id:2122842479 --> @SergeantConfused commented on GitHub (May 21, 2024): Hi @kyrias, Thank you for this report. Yes, Android would not allow intercepting and storing a new passkey when ```requireResidentKey``` is ```true```; However, you should be able to use such a passkey from inside your individual Bitwarden account to log in on mobile, assuming you initially saved it via the browser extension. With regard to the fact that Bitwarden is not being shown as an option when attempting to pass the 2FA stage, that's expected as outlined in the [warning in the documentation](https://bitwarden.com/help/auto-fill-android/#setup-bitwarden-for-use-with-passkeys). I will now proceed and close this GitHub report; Please feel free to [get in touch](https://bitwarden.com/help/) if you have any questions or concerns. Thank you again,
Author
Owner

@kyrias commented on GitHub (May 21, 2024):

Thank you for this report. Yes, Android would not allow intercepting and storing a new passkey when requireResidentKey is true; However, you should be able to use such a passkey from inside your individual Bitwarden account to log in on mobile, assuming you initially saved it via the browser extension. With regard to the fact that Bitwarden is not being shown as an option when attempting to pass the 2FA stage, that's expected as outlined in the warning in the documentation.

Ah, completely missed that note, sorry about that. Is there any upstream Android ticket or similar about this that one can keep track of requesting this to be changed? Because a website setting residentKey to discouraged shouldn't prevent the client from creating a resident key if it wants to.

But using a passkey that was saved using the browser extension doesn't work, so if you're saying that it's supposed to currently work then it seems like this is still a valid bug report?

<!-- gh-comment-id:2122967698 --> @kyrias commented on GitHub (May 21, 2024): > Thank you for this report. Yes, Android would not allow intercepting and storing a new passkey when `requireResidentKey` is `true`; However, you should be able to use such a passkey from inside your individual Bitwarden account to log in on mobile, assuming you initially saved it via the browser extension. With regard to the fact that Bitwarden is not being shown as an option when attempting to pass the 2FA stage, that's expected as outlined in the [warning in the documentation](https://bitwarden.com/help/auto-fill-android/#setup-bitwarden-for-use-with-passkeys). Ah, completely missed that note, sorry about that. Is there any upstream Android ticket or similar about this that one can keep track of requesting this to be changed? Because a website setting `residentKey` to `discouraged` shouldn't prevent the client from creating a resident key if it wants to. But using a passkey that was saved using the browser extension doesn't work, so if you're saying that it's *supposed* to currently work then it seems like this is still a valid bug report?
Author
Owner

@SergeantConfused commented on GitHub (May 22, 2024):

Hi @kyrias,

Just to make sure that you and I are on the same page, by "a passkey that was saved using the browser extension doesn't work" you're referring to the FIDO2 Key that's used as 2FA in your first set of reproduction steps?

Thank you in advance,

<!-- gh-comment-id:2124597267 --> @SergeantConfused commented on GitHub (May 22, 2024): Hi @kyrias, Just to make sure that you and I are on the same page, by "a passkey that was saved using the browser extension doesn't work" you're referring to the FIDO2 Key that's used as 2FA in your first set of reproduction steps? Thank you in advance,
Author
Owner

@kyrias commented on GitHub (May 22, 2024):

Correct.

<!-- gh-comment-id:2125472249 --> @kyrias commented on GitHub (May 22, 2024): Correct.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/android#7911