You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
-[Demonstrating Proof-of-Possession in the Browser Application (for authentication cookies) (BPoP)](#demonstrating-proof-of-possession-in-the-browser-application-for-authentication-cookies-bpop)
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
44
49
@@ -66,8 +71,11 @@ This document makes direct analogs to DPoP, e.g. defining a "BPoP Proof" to matc
66
71
67
72
A website that is its own standalone identity provider (i.e. a website that accepts a username and password) could activate BPoP as part of rending the login form. Then, on the subsequent request, when the website verifies the username and password and issues an authentication cookie, the website could also verify the BPoP proof and record the public key associated with the BPoP proof in the authentication cookie. If this website had user submitted content and such content was subsequently used as part of a stored cross site scripting (XSS) attack, this attack would be unable to steal the BPoP private key and thus the attacker would be unable to use any stolen cookies.
68
73
74
+
BPoP also helps in mitigating the man-in-the-middle attacks where an attacker incercepting the traffic and stealing any artifacts will not be able to apply them without the extra proof we require with this protocol. Same with the on-device attacks which can result in the cookie-jar being stolen, will not be able to use those cookies for acquiring access to other resources.
75
+
69
76
A website that uses a federated identity provider could activate BPoP as part of redirecting to the federated identity provider. Then, on the response back from the federated identity provider, when the website verifies the federation response and issues an authentication cookie, the website could also verify the BPoP proof and record the public key associated with the BPoP proof in the authentication cookie. If this website were vulnerable to a reflected XSS which stole the authentication cookie, the attacker would be unable to use that stolen cookie, as the attacker would be unable to produce a BPoP proof.
70
77
78
+
71
79
BPoP is also not strictly limited to cookies - it can be used to bind any artifact which is issued and accepted by the same web server (e.g. an ASP.NET ViewState).
72
80
73
81
### CNAMEs
@@ -76,6 +84,15 @@ One prominent place where authentication cookies may be shared with multiple par
76
84
77
85
While it is possible for `example.com` to properly audience constrain cookies today (e.g. by issuing one cookie for each subdomain, rather than one cookie in the top-level domain), doing so in practice has proven to be prohibitively cumbersome for many deployments.
78
86
87
+
### Design proposal
88
+
89
+
Here is how BPoP is expected to work end-to-end:
90
+
91
+
1. Webpage user goes to `example.com`, and initiates login. `example.com` redirects to `login.microsoftonline.com`, using javascript or http headers to active binding for `example.com` cookies.
92
+
2.`login.microsoftonline.com`, shows password prompt, javascript or http header activates binding for eSTS cookie
93
+
3. enter password, ESTS SHR in http request, response contains bound eSTS cookie, redirect to example.com with auth code
94
+
4.`example.com` SHR in http request, response from `example.com` contains bound `example.com` cookie
95
+
79
96
### Server activation
80
97
81
98
BPoP is designed to be linked to a classic OAuth session (can be any other authentication mechanism), and when a user makes a request to authenticate, the server also returns a response header `BPoP` to active binding. `BPoP` is a [structured header](https://www.rfc-editor.org/rfc/rfc8941.html) whose value is a dictionary. The following keys are recognized:
@@ -210,6 +227,8 @@ BPoP: enabled, SameSite=None
210
227
211
228
The latest configuration replaces the previous configuration. Replacement occurs for the entire config, not just for configuration elements who appear in the `BPoP` header.
212
229
230
+
Please note that this behavior applies only when there is no enterprise policy override. In case if enterprise policy enabled by the browser config, the BPoP behaves as configured by the policy. More details on key management and storage for enterprise use cases are covered later in this document.
231
+
213
232
### Retrieval model
214
233
215
234
The browser only attaches BPoP proofs to "secure" protocols (as defined by the user agent).
0 commit comments