Search code examples
oauth-2.0openid-connectwebauthn

How does WebAuthn allow dependent web API's to access public key for decrypting credential without having to send the key?

I have familiarity with OAuth 2.0 / OpenID Connect but am new to WebAuthn. I am trying to understand how a scenario using those OAuth flows and connections would work using WebAuthn. I thought by mapping concepts from oauth to webauthn I would be able better understand the concepts.

I think similar to how in OAuth implicit grant flow a client may receive an id_token and access_token, in WebAuthn a client may receive a credential object from the Authenticator using navigator.credential.create.

The part I do not understand is how this credential can reliably be consumed by downstream services. In OAuth a client or server may send "access_tokens" and the receiving servers may request the public keys from the authorities to validate that it hasn't been tampered, is not expired, has correct audience, etc. This relies on the authorities having a publicly available /.well-known endpoint with the public keys.

However, I think because the keys are specific to the authenticator instead of a single shared public key it is not possible to have these be discoverable.

This is where I don't understand how credentials could be consumed by services. I thought the client would have to send the public key WITH the authenticator and client data but this is 3 pieces of information and awkward. Sending a single access_token seems actually cleaner.

I created a graphic to explain visually. (It may have technical inaccuracies, but hopefully the larger point is made clearer) https://excalidraw.com/#json=fIacaTAOUQ9GVgsrJMOPr,yYDVJsmuXos0GfX_Y4fLRQ

Here are the 3 questions embedded in the image:

  1. What data does the client need to send to the server in order for the server to use the data? (Similar to sending access_token)
  2. How would sever get the public key to decrypt data?
  3. Which piece of data is appropriate / standardized to use as the stable user id?

enter image description here

Solution

  • There is a lot of good information in the other answers and comments which I encourage you to read. Although I thought it would be better to consolidate it in a single post which directly responds to the question from OP.

    1. How does WebAuthN allow dependent web API's to access public key for decrypting credential without having to send the key?

      • There were problems with the question:

        • I used the word "decrypt" but this was wrong. The data sent is signed not encrypted and so key is not used to decrypted but verify the signature.
        • I was asking how a part of OAuth process can be done using WebAuthN however, this was misunderstanding. WebAuthN is not intended to solve this part of process so the question is less relevant and doesn't make sense to be answered directly.

      • Others have posted that WebAuthN can be used WITH OAuth so downstream systems can still receive JWTs and verify signatures as normal. How these two protocols are paired is a out of scope.

    2. What data does the client need to send to the server in order for the server to use the data?

    3. How would server get the public key to decrypt data?

      • Again, decrypt is wrong word. Server is not decrypting only verifying signature
      • Also, the word server has multiple meanings based on context and it wasn't clarified in the question.
        • WebAuthN: For the server which acts as Relying Party in WebAuthN context, it will verify signature during authentication requests. However, the server in question was intended to mean the downstream APIs would not be part of WebAuthN.
        • OAuth: As explained by others, theses API servers could still be using OAuth and request public key from provider for verification and token contains necessary IDs and scopes/permissions. (Likely means able to re-use existing JWT middlewares)

    4. Which piece of data is appropriate / standardized to use as the stable user id?

    Hopefully I didn't make too many technical inaccuracies. 😬