Clarify how a user can authenticate from multiple devices

[cjthompson]

The current draft specification makes no attempts to address the question of authentication by a user from different devices.

Consider the following common use cases:

1. A user wishes to access their account from multiple devices that they trust; e.g., a desktop computer, a laptop computer, and a mobile device.
2. A user wishes to access their account from an untrusted device; e.g., a friend's laptop.

The specification doesn't include recommendations to implementers on how to address these common scenarios. Once a private key has been created, how does a user authorize other devices to gain access to the account?

Passwords are portable. As long as one recalls the password, an account can be accessed from any device. If Web Authentication has the goal to replace passwords, then it must address the issue of portability.

[nadalin]

I'm not sure this belongs in the spec as the implementation would not be effected, this is more on the users end on how to manage multiple authenticators

[cjthompson]

I agree as far as the protocol spec is concerned.

The draft spec does already include a section titled "Sample scenarios" that describes possible implementations for various scenarios. I'm suggesting that a new sample scenario to be added that suggests one possible way for an implementer to address the issue of portability.

My concern is that the protocol won't gain user acceptance if credentials are locked to a physical device.

[vijaybh]

@cjthompson , the primary sample scenario described in the spec does in fact show how to access an account from multiple devices. The user authenticates on their laptop (the client) with their phone (the authenticator) and can do the same thing on a different laptop as well. So just like they are able to access their account from any machine on which they can type their password, they can access the account from any machine that can talk to their phone. There doesn't seem to be anything special for the implementer or RP to do.

If you can explain a bit more how the text was confusing (i.e. why the sample scenarios did not seem to align with your expectations) then we can look at clarifying this text. Thanks!

[nadalin]

I believe in some cases like a TPM that this will be the case where the credetials are locked to s specific device and will not be portable

[cjthompson]

@vijaybh - I read through the sample scenarios a few times. While it doesn't explicitly cover the scenario that you describe, it seems clear that if the authenticator is a portable device of some kind, that would allow for logging in from multiple devices.

The Microsoft Account app works this way. I use a username/password to log into my account. A prompt is shown on my phone to accept the login. Once accepted, I am logged in as expected.

I believe my confusion stems from the scenario in which the user's browser is the authenticator. For example, my browser generates the public/private key pair and stores it in a local store (TPM or encrypted or whatever). If the browser generates and stores the key pairs, they lose their portability.

Would it be envisioned that some form of cloud storage of private keys could be used to sync private keys to multiple devices, similar to current password managers? Or, could a third-party website act as an authenticator in a similar way to how OAuth uses a third-party to authenticate a user? If that was true, then one would only need to remember authentication credentials for the third-party system, which would store all the user's private keys.

[nadalin]

The keys are held within the TPM and not exportable and thus are not stored in the cloud, this makes the credentials locked to a specific device

[cjthompson]

Could a third-party website act as an authenticator similar to OAuth?

[nadalin]

I guess I'm not following you as OAuth does not do authentication, only issues access tokens

[equalsJeffH]

Actually, I think @cjthompson has a point here -- note that in discussions wrt webauthn deployment approaches we (webauthn wg) have had, at least one RP is intending to not allow users to register creds that are held on a "non-portable" device, such as a laptop or desktop.

Also, an RP could allow users to register multiple credentials from multiple devices with their account.

Thus, this is further grist for an "implementation considerations" section and I've labled this issue with doc:impl-cons and left it open.

[selfissued]

I think that we could easily just close this, as credential portability is a non-goal. Or we could say in the Implementation Considerations spec saying that "credential portability is a non-goal" and then close it.

[equalsJeffH]

I think there's further nuances here and we should keep it open as-is as grist for an impl-cons section.

[emlun]

This is related to #842 and #422.

[paramsinghvc]

What's the solution to this? It's a very common scenario. People access web apps from their MacBook and phones separately. The credentials can't be ported. And, the webauthn mechanism works by storing the credentials in user machine which means multiple devices have multiple credentials. How does webauthn address this issue of authenticating on multiple devices then? Developers won't be able to use it since this is the case.

[MasterKale]

@paramsinghvc It's going to be the responsibility of the service incorporating Webauthn as an authentication mechanism to coordinate associating multiple authenticators to a single internal user account.

Some types of FIDO2 devices, like Yubikeys, are most flexible in that they can be plugged into multiple devices and used to authenticate. Users could get away with registering a single such device and use it across their laptop, PC, phone, etc... In the case of, say, a MacBook Pro's Touch ID, the sensor is physically tied to the machine and so the user is going to be incapable of using it to log in from their PC. In this second scenario, it'd be up to the back end service to devise a way to empower a registered user to initiate a second attestation process from a logged-in device that would enable initiating attestation on a second device.

The solution to this is for dedicated individuals to start building "turnkey" solutions/packages/dependencies/etc... that make it easy for various frameworks to incorporate this into their authentication flows. I don't foresee this happening overnight, though. After building my own password-less Webauthn-powered OIDC Provider (@cjthompson this might interest you 😛) it became clear to me that there's a non-trivial amount of work required to generalize such functionality for reusability...

EDIT: Here's a simple corresponding RP I created to help demonstrate combining Webauthn with SSO: https://matts-peanut-butter-emporium.netlify.com

[paramsinghvc]

Thanks @MasterKale for throwing light on the same. I see that, you're sending a magic link on user's email which allows it to register a new device when he opens it on a given new device. Hmm, one has to get an email service provider for this; not that straight-forward but yeah makes sense.

[billchenchina]

Thanks @MasterKale for throwing light on the same. I see that, you're sending a magic link on user's email which allows it to register a new device when he opens it on a given new device. Hmm, one has to get an email service provider for this; not that straight-forward but yeah makes sense.

Well, you don't need an email service provider. Just provide user an OTP for them to login on a new device is just ok.

[bdewater]

@paramsinghvc you can use a roaming (USB/NFC/BT) authenticator to bootstrap registration of a new platform authenticator today but in the future a platform authenticator (phone) could connect over bluetooth to other devices (laptop) as well. See https://venturebeat.com/2019/04/10/you-can-now-use-your-android-phone-as-a-2fa-security-key-for-google-accounts/ and https://github.com/w3c/webauthn/pull/909

[Oloompa]

If your user want to sign in from a new device (because he lost/broke previous one or because he doesn't have it with him); is the solution to ask him for a password first and then register the new device ?

Webauthn seems not mature enough.

[emlun]

@Oloompa This problem is not new to WebAuthn: if a user wants to sign in but has forgotten their password, do you ask them for just their username and let them in anyway? If you lose your house key, do you use an override handle to unlock the door without it?

There is no single answer to your question; it will depend on the security requirements of the service, and perhaps the user.

Some services might just send an account recovery e-mail and call it good enough. Some might lock you out until you recover your authenticator or retrieve a backup authenticator you registered before losing the other one. Some might lock you out but provide some intentionally cumbersome account recovery options (see Google's Advanced Protection, for example). Some users might prefer the risk of getting locked out over the risk of someone abusing account recovery procedures to take over their account.

[mamartins]

One more common case that this solution doesn't address:

• I wipe my phone/get a new one, how can I login again on my account? An email isn't enough as it could be compromised. Unfortunately we still need to rely on other 2FA methods like TOTP, SMS, etc.

[emlun]

@mamartins This question has in fact been answered multiple times in this thread already: you use a roaming authenticator.

[mamartins]

But making a USB Security Key mandatory isn't user friendly at all, and it can be lost too...

[arshadnoor]

There are a few things about FIDO2/WebAuthn that create confusion - unfortunately, the mess the authentication industry created over the last 20 years with the stupid "2FA" and "MFA" schemes they invented (instead of trying to make TLS ClientAuth simpler and easier) was primarily responsible for the mess. Leaving that rant aside for the moment, here are facts that might be helpful in understanding what makes FIDO2 easier to work with:

1) This is the first protocol that allows users to have multiple, unique cryptographic key-pairs associated with an account. For over half-a-century, people have been accustomed to associating an account with a single authentication credential, whether it is a single password or a single digital certificate + private-key, etc. FIDO shatters that paradigm and allows you to register dozens of public-keys with a website if you so choose to. When I demonstrate FIDO2, I show people that I have at least 8 public-keys registered from different devices to the demo account: a USB key, an NFC key, TouchID, Android resident-key, Windows Hello on the TPM, etc. I carry 3 different brands of Security Keys (on my keyring that has my home and car keys) to demonstrate that I've never lost that keyring or the Security Keys, and can authenticate to the same account with all these devices. Its not about affordability, or because we happen to be a FOSS FIDO2 Server manufacturer (and must consequently test with dozens of FIDO2 Authenticators); its about changing people's misconceptions that things have to be a certain way to be successfully adopted.: that there has to be one, universal FIDO2 Authenticator for the world to adopt it. Once you step back from that notion, and life becomes easier;

2) Depending on the secure element on a device, a key-pair does NOT have be locked down to a specific device - they can be ported if the secure element design supports a secure way of transporting keys from one device to another. In our experience, keys registered on a TPM can be ported to another TPM securely - through a process called "key-migration"; this has existed on TPMs since 1.2 (more than 12 years ago). I know this, because our appliances that provide key-management security have been using this capability to migrate encrypted keys from one appliance to another to establish key-management clusters for HA/DR. You can migrate signing-keys and encryption-keys (storage-keys in TPM terminology) very securely and conveniently with this TCG-defined process. However, you must have the tools to do this - the TCG spec tells you how to do this securely. What I cannot speak for are the secure elements on mobile devices and other platforms where resident keys are stored. The secure element manufacturers could attempt to provide a secure process to do this, but I wouldn't hold my breath - IMO, its cheaper to buy a $10 Security Key and use it as your own "migration tool" to create FIDO2 credentials on multiple devices to the same account.

I would encourage technologists to not get too hung up on trying to shield backup and recovery procedures from end-users - the more you dumb them down, the more headaches you create for the industry because somewhere along the way, someone is going to make a mistake and FIDO2/WebAuthn could get compromised because of implementation flaws. Better to let every Authenticator manufacturer create the most secure compartment they can key management, and users just learn to spend $10 on an external Security Key as a backup/recovery device.

Perhaps, we need to start calling "Security Keys" Backup Keys, Recovery Keys or Convenience Keys to get consumers educated that this is not to be shunned, but rather, to be embraced.

[Oloompa]

I still don't understand how both user and dev can handle generic use case of authentication without increasing complexity using this new protocol. This protocol seems to only help key manufacturers to make more money.

Do you really think i can ask my customer to buy a key in order to use my app ? Do you think a user can use it's smartphone to sign in without any other way to sign in if he lost the smartphone ? (cause majority will not buy a key) Do you think a user who buy two key will register each key on each app ?

I don't think this protocol will be use in its current state. It really looks terrible...

[mamartins]

@arshadnoor I do get your point, and I agree with it to a certain extent. Eventually everyone may embrace security keys and it will be an absurd consider that someone might not have one, but while that will probably be true in 10 years we can't ignore how today things work. How security freak does a company have to be to risk going bankrupt because it's mandatory for its clients to buy a 10$ security key, so @Oloompa is also right. We have companies like Visa or Mastercard that prefer to keep their unsecure networks as it would be more costly (commercially) to do it instead of assuming fraud losses!

$10 might not look too much in USA or Europe but consider Asia or Latin America and things change dramatically. Companies cannot afford to obligate their users to spend money and at same time try to thrive commercially. Most of companies are trying to convince users to pay for their services to become profitable, now add the requirement that users will have to pay an extra $10 to be secure and they can mostly certain close their businesses.

[arshadnoor]

I don't disagree with the current economics @mamartins / @Oloompa. $10 is too expensive for APAC. For now. But, all new technologies go through this curve. What some industries should recognize is that it will be less expensive for them to give away Security Keys to customers than to waste time/money with all the other crap they buy/implement to do "risk scoring" on the back-end to minimize breaches and fraud.

Privacy laws are going to force companies to make a trade-off: do they just force consumers towards FIDO2 - a privacy protecting protocol (so long as you don't use a third-party IDP) - or waste more time/money trying to protect PII that they glean from the users platform? I think the economics are already in favor of forcing users towards FIDO2. The EU doled out 500M Euro of fines in 18 months of GDPR; California's Consumer Privacy Act ('the American GDPR) will allow consumers to sue companies for $750 per record per occurrence of a breach of PII; and California considers anything that can uniquely identify an individual to be PII, including IP addresses, "browser fingerprints", GPS locations, etc. Many US states are getting ready to pass their own privacy laws modeled along the lines of the CCPA (thanks to an incompetent Congress in Washington D.C.).

What makes sense in the long-run is for banks, brokerages, lawyers, accountants, etc. to start giving out a Security Key with their brand label to new customers who open accounts with them; for automobile companies to embed a FIDO2 Authenticator in their key-fobs; for car-rental companies and hotels to give away their branded FIDO2 keys to their Gold customers (I abandoned Marriott hotels after 25 years of using them and having achieved Platinum status because of their breach - I cannot tell you how many times I asked them to implement FIDO authentication on their site over the last 5 years); for luxury brand jewelry companies to embed secure elements within their watches, rings, necklaces, ear-rings, and for computer/laptop companies to include a FIDO2 Authenticator with each new computer purchased (in addition to the embedded secure element on their desktop/laptop).

Does this add costs to the product the consumer is buying? Yes, it does. But, considering the cost of what they're spending for the other product they're buying, the $5 Security Key embedded in their primary product will be negligible and irrelevant. Not only will consumers win with a backup/recovery key on their key-chain, but so will Relying Party sites because they can eliminate some of the useless security products they buy to mitigate their risks on the back-end. And, they will be able to claim Strong Customer Authentication for GDPR, PSD2, CCPA, PDPA and all the other privacy laws that will blanket the world eventually.

We all need to see the future for what it will make possible for us if our systems and applications were more secure - not get bogged down with the current debris of passwords and 2FA/MFA junk that prevents us from achieving a more secure future.

[Oloompa]

@arshadnoor is right the majority of final customer will not move first to a dedicated key. The first step (for a final user) would be to use the device they own: their smartphone / watch.

And they will not buy a key for a long so if you want this protocol to be really used by business, the dev and users need a simple and secure way to recover from a single device lost.

If the only solution (for a device lost/broken/stolen) is to use the email/sms then this protocol offer nothing more except more works for dev teams and cost for users. Then it has no chance to be use in the real world.

[Ali-Amir]

I am a bit confused about a multi-device multi-website scenario and was wondering if someone could help me out with that:

A user uses their phone as their key and they are registered on a lot of websites with this phone (abc.xyz, example.com, etc) via some FIDO2 compliant authenticator app. At some point they will upgrade their phone (get a newer Pixel/iPhone/etc) and at that time what is the spec's recommendation for enabling the new phone on all of the existing accounts (abc.xyz, example.com, etc)?

There are approaches that an authenticator app could take to address that such as "securely" migrating existing credentials to the new device or forcing the user to manually add the device to the websites. But does FIDO2 provide a recommendation for which approach an authenticator app should take? My understanding from the thread is that this might be something outside of the specification and is the authenticator's reliability. But this seems like very common use case and it would be great to have a recommendation (unless it's already there and I missed it).

[nicksteele]

what is the spec's recommendation for enabling the new phone on all of the existing accounts (abc.xyz, example.com, etc)?

The WebAuthn specification doesn't have any recommendation for this flow, it would be up to the authenticator vendor (Apple, Google, Samsung, etc) to provide a secure method for the transference of key material. This doesn't mean the specification couldn't help define this however, for example there could be a WebAuthn extension to help facilitate this, but realistically this would be something handled by the vendor.

My understanding from the thread is that this might be something outside of the specification and is the authenticator's reliability.

That's my understanding as well

Does FIDO2 provide a recommendation for which approach an authenticator app should take?

No, or at least not at this time. Personally I think this should be something defined by the authenticator vendors. As far as I know the only hardware vendor to write anything about this topic is Yubico with their work on the account recovery extension .

[emlun]

@Ali-Amir @nicksteele Yeah, this is still a mostly unsolved problem at this time, the spec offers no official guidance yet. There's more discussion on this and some proposed solutions in issue #931.

[Ali-Amir]

@nicksteele @emlun I see, thank you for confirming this. I will keep track of the linked issue.

[arshadnoor]

There are a few safety guards on such a use-case, Dominic. If you have a Security Key that does not integrate biometrics or a PIN, and only checks for "User Presence" (UP), then:

1) The attacker would have to know which websites have registered this key - admittedly, this is a small hurdle because they will try it at the most common larges sites first to see if it works - but most sites that are concerned about security will still ask for a password if the Security Key only supports UP (which is common with the older U2F Security Keys);

2) The attacker has to know the username on the website to be able to generate the correct response from the FIDO Server - there is not only a challenge, but also a list of acceptable "key handles", public-keys and other metadata that will authenticate the response. While you might try to guess at what the username might be, it might work, it might not - but its still another hurdle.

If you really want to be secure on a site you consider too risky to be compromised on, get yourself a "user verifying" (UV) Security Key - with a biometric reader or a PIN; this will add another factor of protection to your account if you lose the Security Key.

Right now, I don't know of any site that accepts a Security Key without asking for your username AND password before presenting the FIDO challenge. The only financial site I know at that accepts a Security Key is Vanguard; it still requires authenticating with a username/password before you see the FIDO challenge. Their policy is that they only accept Yubikeys; I'm not happy with that and have complained. They claim they're updating their site to accept other Security Keys - but it either reflects little understanding of FIDO or they thought they were being very risk-averse by accepting just one brand of Security Keys. I wonder if they know about this paper yet - Yubikey and Feitian are also implicated in the story besides Google:

https://arstechnica.com/information-technology/2021/01/hackers-can-clone-google-titan-2fa-keys-using-a-side-channel-in-nxp-chips/

Arshad Noor StrongKey

On 1/10/21 7:29 AM, Dominic Tobias wrote:

I don't disagree with the current economics @mamartins
<https://github.com/mamartins> / @Oloompa
<https://github.com/Oloompa>. $10 is too expensive for APAC. For
now. But, all new technologies go through this curve. What some
industries should recognize is that it will be less expensive for
them to give away Security Keys to customers than to waste
time/money with all the other crap they buy/implement to do "risk
scoring" on the back-end to minimize breaches and fraud.

This is an interesting point, maybe I'm naive here but I have a Yubikey and it has nothing that authenticates me. All someone needs to do is steal/find it and have access to my accounts. How is that more secure than a password!?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/webauthn/issues/151#issuecomment-757494694, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABWSVTSJ3BY6GBTDA74RJ6LSZHBUBANCNFSM4CKV35SA.

[knightcode]

After reading this thread, I'm still left with a question of what to do with the second browser. Consider a user who has successfully registered the internal authenticator (Touch ID, Face ID, etc) with my server. When this user visits the log-in page on a different device and provides his/her/zer identifer (email address), the app is confronted with a choice of which authentication strategy to pursue, webauthn being one of them. The email address is sent up to the server, the user is looked up, and, at the moment, I'm using the presence of the public key to indicate that we should try webauthn. I don't see a way to associate the public key with the originating device. If we had an identifier for the authenticator that could be stored during registration and sent with the email address to the server, we could decide to pursue a different strategy. As it stands, I'm left trying to parse different failures in order to figure out the best course of action.

[arshadnoor]

Its interesting how 6 months can make a difference; you may be in luck, Dylan (@knightcode).

With the introduction of Passkey by Apple, if the user has synchronized their FIDO key with iCloud, that key will now be available on all supported/registered Apple devices for passwordless FIDO authentication. It is still an early release and it remains to be seen how it will work out when finally released and as it matures.

Speaking for myself, I would not be comfortable trusting my encrypted private-key in the cloud - even if they are using cryptographic hardware modules to further protect it or get access to it - but, that's me. Most users might not care because they will get to use "true" passwordless authentication instead of the mirage they have currently with TouchID/FaceID being the checkpoint to a password (that can still be attacked in myriad ways).

The WebAuthn community appears to be enamored of "syncable FIDO credentials" in the mold of Passkey. While I haven't parsed that thread, I think that while it will solve one problem it will likely give rise to others.

If you're unwilling to wait for Passkey/SyncableKeys to be a reality, the flow in this posting might offer a path.

[knightcode]

Thanks.... and, yeah, it seems like I have to initiate WebAuthn with some user interaction, and let them figure out if it'll work.

Giving authenticator an ID is a bad idea, though, on second thought. Assuming it survives clearing the browser data, then it's an ID advertisers would misuse.

Edit: To be clear, I wasn't suggesting the need for portable keys. I was arguing that something is needed to support a better user experience whenever the current device isn't the one registered with the server for a given user.

[Firstyear]

At the end of the day @knightcode this is something that webauthn has left to be resolved by RP's to work out the UX flow for when you have multiple devices/browsers, or multiple authenticators available. I think we'll see multiple different ways that people end up managing this, especially once you consider non-homogenous authenticator classes that webauthn by design can't mix/match.

[emlun]

especially once you consider non-homogenous authenticator classes that webauthn by design can't mix/match

Would you like to elaborate on this? This is definitely not an intentional design goal, if I understand correctly what you mean.

[knightcode]

I'm fully aware that my current implementation might be flawed, but I guess what I was hoping to do is ask our server for a challenge and credential IDs as soon as the username/email field is blurred. If IDs come back, it'd be nice to trigger webauthn automatically and get back a failure saying "none of these IDs are here" which also doesn't trigger any native browser UI, so that I don't have to let the user know that we failed trying to do something they didn't even ask for... presumably, he/she/ze already knows that it was going to fail. This is opposed to other errors where maybe it's appropriate to inform the user that we tried but it's not working.

Chrome, at least, was still engaging its UI to inform the user that none of the keys provided were available.

Given this, I've pushed the webauthn flow to an auxiliary thing. The primary UI is still username/password + maybe OTP, and a button was added for the user to trigger webauthn if they feel like it.

[agl]

If IDs come back, it'd be nice to trigger webauthn automatically and get back a failure saying "none of these IDs are here" which also doesn't trigger any native browser UI

The desire is quite understandable but we can't allow websites to silently probe the browser for the user's identity for the obvious reasons.

and a button was added for the user to trigger webauthn if they feel like it.

For 1st-factor WebAuthn, that's correct. The answer in the future will be that browsers will support WebAuthn via autofill (#1637) so that the browser can present the user a list of applicable credentials when focusing the username field.

[Firstyear]

especially once you consider non-homogenous authenticator classes that webauthn by design can't mix/match

Would you like to elaborate on this? This is definitely not an intentional design goal, if I understand correctly what you mean.

I have a write up on the topic here:

https://github.com/kanidm/webauthn-rs/blob/master/designs/authentication-use-cases.md

the tl;dr is you can't mix verified and un-verified credentials, or resident/non-resident credentials. The UI must always perform pre-selection to help select what challenges can be sent to navigator.credentials.get. So even if devices can share credentials, there still is an expectation on RP's to implement a UX to do filtering of what can proceed.

[knightcode]

If IDs come back, it'd be nice to trigger webauthn automatically and get back a failure saying "none of these IDs are here" which also doesn't trigger any native browser UI

The desire is quite understandable but we can't allow websites to silently probe the browser for the user's identity for the obvious reasons.

The website is providing a list of IDs it knows about, though. And it seems like the ID space is huge. If the query limits possible hits to the current web domain only, the danger is that a script might start silently iterating through all possible IDs to find the one or two working keys on this device? That's the danger?

[emlun]

@knightcode Correct, but remember that techniques like browser fingerprinting can likely narrow the searchable space down to a manageable size. Then the website could use the silent probe to exactly identify the user without the user's consent. This does presuppose that the user has at some point authorized a credential creation for that site, but it's far easier to confuse a user into doing that once than into doing it every time you want to identify them.

[Lonli-Lokli]

@paramsinghvc It's going to be the responsibility of the service incorporating Webauthn as an authentication mechanism to coordinate associating multiple authenticators to a single internal user account.

Some types of FIDO2 devices, like Yubikeys, are most flexible in that they can be plugged into multiple devices and used to authenticate. Users could get away with registering a single such device and use it across their laptop, PC, phone, etc... In the case of, say, a MacBook Pro's Touch ID, the sensor is physically tied to the machine and so the user is going to be incapable of using it to log in from their PC. In this second scenario, it'd be up to the back end service to devise a way to empower a registered user to initiate a second attestation process from a logged-in device that would enable initiating attestation on a second device.

The solution to this is for dedicated individuals to start building "turnkey" solutions/packages/dependencies/etc... that make it easy for various frameworks to incorporate this into their authentication flows. I don't foresee this happening overnight, though. After building my own password-less Webauthn-powered OIDC Provider (@cjthompson this might interest you 😛) it became clear to me that there's a non-trivial amount of work required to generalize such functionality for reusability...

EDIT: Here's a simple corresponding RP I created to help demonstrate combining Webauthn with SSO: https://matts-peanut-butter-emporium.netlify.com

@MasterKale what IdP you use for magic links & webauthn in your demo, can you please share? Is it possible to use it for free ?

[David-Chadwick]

Also, an RP could allow users to register multiple credentials from multiple devices with their account.

Jeff. This is exactly what we have done in our implementation.

[lkj4]

Why was this issue closed? I couldn't find a clarification of how a user can auth from multiple devices. The solution isn't roaming auth (confusing name btw)—Webauthn's core isn't about using something like an external Yubikey. If I wanted auth via Yubikey I could use a couple of other ways than \Webauthn to authenticate.

[james-d-elliott]

The methods of authentication are basically implementation specific. A user may have a cross-platform aithenticator where this does not exist as a barrier. Or they may choose to use a platform authenticator where there are two options; the implementation of the platform authenticator offers the ability to export the credential to another device via sync or other means.. or the user registers a platform authenticator with the relevant relying party (think this is the terminology.. basically the service trusting the credentials) for each device they want to authenticate with.

I think the reason this is closed is because it's out of scope for the specification since it covers the method of authentication not the individual implementation mechanics of every facet of webauthn.

[emlun]

The solution isn't roaming auth

It is, though. If you want to (1) log in from multiple devices, but (2) always enforce WebAuthn authentication for every login and (3) not copy private keys, then your only option is to use an authenticator with multiple connectivity options. Otherwise you'll have to relax at least one of the requirements (1), (2) and (3). Some (most?) websites do relax (2) and allow some other method of 2FA or account recovery. Some authenticator vendors relax (3) and copy private keys between devices via cloud sync or similar.

But note that a "roaming authenticator" doesn't have to be a YubiKey or similar "security key" device, it can also be a smartphone for example. Mobile OS vendors are now starting to support acting as a roaming authenticator via Bluetooth. This means a platform credential on the phone can be used both as a "built-in" credential on the phone and as a roaming credential on other devices.

[daniel-nagy]

My company is planning on implementing password-less auth using text message verification codes. I decided to investigate Webauthn as an alternative to sending text messages, primarily to reduce the cost of sending text messages. However, I don't think I can recommend Webauthn as a replacement for sending text messages for password-less auth.

I think the concern of authenticating from multiple devices is real. While using a smart phone as a roaming authenticator, at least in the US, sounds promising. It is still susceptible to the phone being lost, stolen, broken, restored, or replaced. At which point the user would be locked out and a second form of authentication will be necessary to restore access. At least with text messages, the user would regain access as soon as they could start receiving text messages again. It is also unclear what the flow would be to get the user to use their phone as the authenticator when they are registering, for the first time, from their laptop for example.

I don't think it is reasonable to expect people to use a secondary external device to authenticate on their phone. In other words, I don't think it is reasonable to expect people to plug a yubikey into their phone to authenticate. At least not at this time.

[FlxMgdnz]

@daniel-nagy you might want to take a look at how WebAuthn will evolve into passkeys until the end of the year. Especially on Apple and Android devices your use case should be pretty much covered. I suggest you base your regular login on passkeys, and only fall back to text messages on older devices or in case a user loses their passkey device and switches the platform, e.g. from iOS to Android.

[daniel-nagy]

Thanks @FlxMgdnz, passkeys look promising. It seems text message verification codes will still be necessary but passkeys could reduce the number of text messages and improve the UX after the user is registered on supported platforms.