George Fletcher presented Browser Changes Impacting Identity Flows at the OIDF Workshop at Verizon Media on Monday, September 30, 2019 in Sunnyvale, CA.

1. Browser Changes impacting
Identity Flows
OpenID Foundation Workshop

2. Introduction
SameSite Policy Impacts
ITP Policy Impacts
Browser “VPNs” to mask browser IP addresses
navigator.isLoggedIn() proposal
HTTP State Tokens

3. Acknowledgements
Filip Skokan
Mika Mannermaa
Ajinkya Kshirsagar

4. SameSite policy changes
SameSite=Strict
● Only sent when page loaded in the browser exactly matches the domain of
the cookie
SameSite=Lax
● Cookie is sent from a non-matching domain if and only if the user explicitly
clicks a link that initiated the load of the off-domain page
SameSite=None; Secure
● The default that we have today except that these cookies will only be sent
over secure connections (HTTPS)

5. What is affected by SameSite=strict
It’s fair to say that mostly everything, Client requesting an
authentication/authorization response from an AS through the regular browser
redirect flow will get hindered like so
● The RP session cookie (in which regularly nonce and state is stored) will not be sent with the
callback.
● The OP session cookie will not be sent with the redirect and therefore AS will resolve to
authenticating the end-user again. It will set a new session cookie and the old one will become
orphaned.
● When an AS redirects to an upstream IdP (facebook, google, etc) it won’t be able to consume the
callback since then we are the RP and we can’t load our session cookie with the state/nonce details
we need to consume a callback.

6. What is affected by SameSite=lax
Any hidden iframe mechanism
● response_mode=web_message used for silently renewing tokens, the origin
of the request is not the AS hence the AS session cookie is disqualified from
being sent.
● OIDC Session Management and Logout Specifications
○ Session Status Change Notification - the origin of the request is not the AS hence the
individual RP session state cookies are disqualified from being accessible to the javascript
context.
○ Front-Channel RP Logout iframe - the origin of the request is not the RP website hence the RP
session cookies are disqualified from being sent.

7. What is affected by SameSite=lax
POST based protocol messages
● response_mode=form_post used to return tokens via the front-channel but directly to the RP
backend service. The origin of the request is the AS hence the RP session cookie (in which regularly
nonce and state is stored) will not be sent with the callback. An RP will fail to consume the callback.
● POST to the authorization_endpoint - the OP session cookie will not be sent with the POST request
and therefore the AS will resort to authenticating the end-user again. It will set a new session cookie
and the old one will become orphaned.
● POST to the end_session_endpoint - the OP session cookie will not be sent with the POST request
and therefore the AS will not be able to identify the authenticated session and logout will not be
performed.

8. What is impacted by SameSite=none
● Cookies marked as SameSite=none MUST also be flagged as ‘Secure’
● This means that these cookies will only be sent to an HTTPS endpoint
● This means that if the RP is using SameSite=none cookies, their callback URI
MUST be HTTPS
● Developers now need to run their dev endpoints as secure (HTTPS)
endpoints

9. Upcoming Changes to current SameSite policy
● Google calls this Incrementally Better Cookies in their individual draft and it
consists of two changes, one being a prerequisite for the other.
○ Default sameSite cookie attribute changes from “none” to “lax”
○ Cookies with sameSite attribute none also have to be secure
● Intent to ship in Chrome by default has been set to version 80 (due in
February 2020), Firefox version 69 behind a preference toggle.
○ https://www.chromestatus.com/feature/5088147346030592
○ https://www.chromestatus.com/feature/5633521622188032
○ https://groups.google.com/forum/#!msg/mozilla.dev.platform/nx2uP0CzA9k/BNVPWDHsAQAJ
●

10. What the change means
When a set-cookie header does not have a sameSite attribute, instead of
defaulting to none (today’s behaviour) it will be defaulted to lax.
When a set-cookie header has an unrecognized sameSite attribute, instead of
defaulting to none (today’s behaviour) it will be defaulted to lax.

11. Impact on Authorization Servers
● Inventory existing flows to determine impact
○ Depending on the existing supported flows (e.g. top-level full page redirects) no changes may
be necessary
● What to do?
○ In order to ensure all existing flows are still working send sameSite=none with all cookies that
are intended to be accessed cross-origin.
○ Use two cookies
● Risk:
○ Some, to work around a known WebKit bug which is still in effect (see below “Existing WebKit
bug”).

12. Impact on Relying Parties
● If a client currently sets their cookies to either of the defined values, it will
continue to work after the default sameSite value changes as well.
● If a client currently uses response type query or fragment, it will continue to
work after the default sameSite value changes as well
● Native SDKs (using custom scheme or claimed https uris) are not affected,
these use either query or fragment.
● If a client uses response_mode=form_post
○ the cookies used to convey a session or ones that contain the request parameters like nonce,
state, etc need to be set to “none”
○ - or -
○ the implementation must be changed to response_mode=fragment with a self-submitting form
being rendered on the client’s GET

13. Temporary workaround for login flows
● If a cookie has been set (session or persistent) within the last 2 minutes
without an explicit SameSite value, it will still be sent with FORM posts
Impacts
● Allows existing flows to *mostly* NOT break when deployed
● Any FROM response based login flow that takes more than 2 minutes will
break as the cookies will not be sent

14. SameSite=none webkit bug
Older instances of iOS webkit do not correctly handle a cookie explicitly marked as
SameSite=none. Instead it defaults the cookie to the ‘strict’ policy.
Resolution:
● At this point it doesn’t appear that older version of webkit will be patched
● Recommended solution is to use two cookies one explicit set to
SameSite=none and one with no SameSite attribute
○ This requires the service receiving the cookies to work through what to do if both arrive :)

15. ITP 2.X
Sites flagged as “tracking sites” have their cookies wiped every 30 days unless the
user explicitly interacts with the eTLD+1. This applies to local storage as well. [ITP
2.1]
Persistent Cookies set via JS are wiped after 24 hours. [ITP 2.2]
Cookies won’t be sent at all in 3rd party contexts.
In Safari 13, local storage will be wiped (after 7 days of no activity to that domain)
if coming to a site from a “tracker site” and request contains query parameters.
[ITP 2.3]
2.3 - https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/

16. Impact of ITP 2.3
● Since OIDC/OAuth authorization_code flow redirects with query parameters, it
appears this will set the RP domain to have it’s localStorage wiped 7 days
after the user last accesses that domain

17. Browser based “VPNs”
● Concern that request features like IP address might uniquely identify a user
and enable tracking
● Browsers currently collecting metrics regarding this “tracking” approach
● Planning to support “remote proxying” of requests so that IPs are multiplexed
across random users
https://www.technadu.com/firefox-premium-version-integrated-vpn/70071/
https://private-network.firefox.com/
https://github.com/bslassey/privacy-budget
https://blog.cloudflare.com/announcing-warp-plus/

18. navigator.isLoggedIn() proposal
“For the purposes of client-side storage/state, the behavior of the web platform has been “logged in by default,” meaning as
soon as the browser loads a webpage, that page can store data virtually forever on the device, and the browser may have
to treat the user as logged in to that website. That is a serious privacy issue. Long term storage should instead be tied to
where the user is truly logged in.”
“If websites were allowed to set the IsLoggedIn status whenever they want, it would not constitute a trustworthy signal
and would most likely be abused for user tracking. We must therefore make sure that IsLoggedIn can only be set when
the browser is convinced that the user meant to log in or the user is already logged in and wants to stay logged in.”
“If websites were allowed to set the IsLoggedIn status whenever they want, it would not constitute a trustworthy signal
and would most likely be abused for user tracking. We must therefore make sure that IsLoggedIn can only be set when
the browser is convinced that the user meant to log in or the user is already logged in and wants to stay logged in.”
https://lists.w3.org/Archives/Public/public-webappsec/2019Sep/0004.html

19. navigator.isLoggedIn() proposal
There are several ways the browser could make sure the IsLoggedIn status is trustworthy:
● Require websites to use of WebAuthn or a password manager (including Credential Management) before calling the
API.
● Require websites to take the user through a login flow according to rules that the browser can check. This would be
the escape hatch for websites who can’t or don’t want to use WebAuthn or a password manager but still want to set
the IsLoggedIn bit.
● Show browser UI acquiring user intent when IsLoggedIn is set. Example: A prompt.
● Continuously show browser UI indicating an active logged in session on the particular website. Example: Some kind
of indicator in the URL bar.
● Delayed browser UI acquiring user intent to stay logged in, shown some time after the IsLoggedIn status was set.
Example: Seven days after IsLoggedIn was set – “Do you want to stay logged in to news.example?”
● Requiring engagement to maintain logged in status. Example: Require user interaction as first party website at least
every N days to stay logged in. The browser can hide instead of delete the credential token past this kind of expiry to
allow for quick resurrection of the logged in session.

20. navigator.isLoggedIn() proposal
Some websites allow the user to use an existing account with a federated login provider to bootstrap a
new local user account and subsequently log in. The IsLoggedIn API needs to support such logins.
● First, the federated login provider needs to call the API on its side, possibly after the user has
clicked a “Log in with X” button:
● For the promise to resolve, the user needs to already have the IsLoggedIn status set for the
federated login provider, i.e. the user needs to be logged in to the provider first.

21. HTTP State Tokens
https://mikewest.github.io/http-state-tokens/draft-west-http-state-tokens.html
While not new, this is referenced in the “navigator.isLoggedIn()” proposal as the
“better” way to manage state and logged in sessions.
Also wanted to discuss whether it’s possible to use state tokens to “sender
constrain” cookies (ala token-binding) but with a different mechanism

22. General Discussion