The credentials are stored in Azure AD. Azure AD supports OpenID Connect. The clients use a modern browser using Android/iPhone or Windows Hello.
Is it possible to implement the WebAuthn API with your website. And when a user has no private/public FIDO key stored for your website let the user authenticate with OpenID Connect and their Azure AD credentials? And the next time they would like to use your website they don’t have to authenticate with their Azure AD credentials anymore because there is a FIDO key on their device four your website?
Or am I saying something completely stupid and does WebAuthn not work this way?
I hoped to find an example where they did implement such a use case but it is difficult to find something on this topic. I found this topic How does WebAuthn allow dependent web API's to access public key for decrypting credential without having to send the key? but it still doesn’t explain if I’m on the right track.
2
Answers
There is no direct relationship between WebAuthn and a federation protocol, like OpenID Connect. They are, however, often used together, but with WebAuthn being used to authenticate the user to the IdP (the OIDC provider).
Federation should not be mixed with local credentials. I would recommend not doing this as it will be very confusing to the user.
The general pattern with OIDC is to never code authentication into your apps. Instead you run a code flow and the authorization server deals with credentials, including WebAuthn keys, so that your apps do not need to. Instead your apps and APIs receive tokens, with a subject claim that identifies the user.
Typically you then do some configuration in the authorization server to get your desired behaviour. One option is to allow users to choose between WebAuthn and passwords on every login. Another is to prompt for a username to identify the user, then look up their authentication method. Eg if they have existing WebAuthn keys, bypass authentication selection screens.
A good way to reason about this is to create flow charts first, eg for new and future users, then choose an authorization server that supports the behaviour you need, which will require some extensibility. Also see the Azure AD passwordless options.