I am proposing this scheme for federated authentication and WebCrypto. I am not sure if something like this (or better) exists, please do send me related material.


  1. Alice's Browser, BROWSER
  2. Bob's server, BOB
  3. Alice's server, ALICE


Identities are domain names and each server has access control list on each resources.

  • Bob writes in the access control file "alice.com" can read "/foo"
  • Alice wants to read foo


tl;dr version:

  • Alice's Browser tries to access a resource on Bob's server, Bob replies with unauthorized message and a nonce
  • Alice generates a key in her browser with webcrypto and keeps that in memory
  • Alice uploads her key on her website
  • Alice signs the nonce, the address of bob server and the address of her key
  • Bob receives the message and checks if the location that alice mentioned has the public key that verifies the signature


1. Alice's Browser tries to access a resource on Bob's server

BROWSER   -------------- GET /foo ---------------------->  BOB
BROWSER   <------------- RESPONSE 401 {nonce} -----------  BOB

2. BROWSER uses WebCrypto to generate Pub/Priv key pair

3. Alice's post her new key on her server

BROWSER   -------------- POST /keys/nonce -------------->  ALICE
                         { Pub }
BROWSER   <------------- RESPONSE 200 -------------------  ALICE

4. Alice's Browser signs the location of the key, the nonce and
   the Bob's Server origin

BROWSER   -------------- POST /foo --------------------->  BOB
                         Sign(location, nonce, bob)

5. Bob's server gets the advertised location

          BOB -------------- GET /keys/nonce --------------->  ALICE
          BOB <------------- RESPONSE {Pub} -----------------  ALICE

6. Bob's server verifies the signature

BROWSER   <------------- RESPONSE 200 -------------------  BOB
                         {set cookie}


  • Is there any pitfall I am not seeing?
  • Can any attack happen in point #4 of the diagram?
  • Does this scheme exist or have a name?

1 Answer 1


What you are describing is very similar to PoP/RFC7800 (Proof-of-Possession Key Semantics for JSON Web Tokens). (It's also somewhat similar to what AC/DC (Authorization Cross Domain Code) is trying to do.)

With PoP, the proposed steps 1 & 2 are the same: BOB (called Recipient) issues a nonce with the 401 response, Browser (called Presenter) generates a Public/Private key pair to send to the server ALICE (called Issuer). Step 3 is also very similar - Browser/Presenter sends the request with the public key to ALICE/Issuer.

PoP and your proposed protocol diverge slightly after Step 3 -- whereas you're storing the public key + signed nonce on ALICE's server, in PoP, ALICE/Issuer simply signs the public key and returns it in the response (in a JWT). The Browser/Presenter then forwards the JWT from the Issuer, adding the nonce (which it signs itself with its private key), to the Recipient.

The Recipient can then verify several things: a) that the Browser/Presenter is the one that received the initial nonce (this prevents client token hijacking), and b) that the Browser/Presenter really holds the JWT signed by the Issuer.

Is there any pitfall I am not seeing?

Both your proposal and PoP accomplish the following:

  1. They protect against client token hijacking by verifying that the Browser/Presenter is the same one that received the nonce in the original 401 Unauthorized response.
  2. They verify that the Browser/Presenter was authenticated correctly to the Issuer -- with your proposal, because the Issuer permitted the POST to /keys/nonce, and with PoP, because the Issuer returned a JWT, signed by itself, that included the browser's public key.

What your proposal does not address is the following important issue:

Given that you're talking about an in-browser application (the Browser/Presenter), how does that application authenticate with ALICE/Issuer? That is, given that the Issuer accepts a POST to /keys/nonce, presumably it has verified the client and has authenticated the user. But how? OAuth2 and OpenID Connect (with which PoP is designed to work) have very specific mechanisms for authenticating public (in-browser) client apps to the Issuer, with redirect protection and so on, because it's not an easy task, and prone to a lot of security holes. It's likely that you're intending to use some sort of cookie mechanism, but if the browser-side app/Presenter is running from a different origin than the Issuer, how is the issuer going to authenticate it?

This is relevant for in-browser apps, but also especially relevant for native apps, mobile apps, or traditional server-side web applications. How does the proposed scheme attempt to address authentication with those?

Can any attack happen in point #4 of the diagram?

Not that I can see, although you don't even have to do a POST here, you can do a plain GET and include the Sign(location, nonce, bob) part in the Authorization: header, bearer token style.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .