|
1 | | -# Explainer: IsLoggedIn |
2 | | - |
3 | | -## Introduction |
4 | | - |
5 | | -This explainer proposes an API called IsLoggedIn with which websites can inform the web |
6 | | -browser of the user's login state. |
7 | | - |
8 | | -Currently, web browsers have no way of knowing if the user is logged in to a particular |
9 | | -website. Neither the existence of cookies nor frequent/recent user interaction can serve |
10 | | -that purpose since most users have cookies for and interact with plenty of websites they |
11 | | -are not logged in to. |
12 | | - |
13 | | -### Why Do Browsers Need To Know? |
14 | | - |
15 | | -The current behavior of the web is “logged in by default,” meaning as soon as the |
16 | | -browser loads a webpage, that page can store data such as cookies virtually forever on |
17 | | -the device. That is a serious privacy issue and also bad for disk and backup space. |
18 | | -Long term storage should instead be tied to where the user is truly logged in. |
19 | | - |
20 | | -There could be other powerful features and relaxations of restrictions besides storage |
21 | | -that the web browser only wants to offer to websites where the user is logged in. |
22 | | - |
23 | | -The ability to do these things requires knowledge of where the user is logged in. |
24 | | - |
25 | | -## Existing Functionality |
26 | | - |
27 | | -In olden times, Basic/Digest Authentication offered a way for browsers to know where the |
28 | | -user was logged in and help them to stay logged in. However, there was never a way to |
29 | | -log out. Regardless, those technologies are now obsolete for many reasons. Today, |
30 | | -[WebAuthn](https://w3c.github.io/webauthn/) and password managers (including the use of |
31 | | -[Credential Management](https://w3c.github.io/webappsec-credential-management/)) offer a |
32 | | -browser-managed way to log in but those features neither cover the expiry of the logged |
33 | | -in session nor the act of logging out. |
34 | | - |
35 | | -Cookies and other kinds of storage may carry login state but there is no way to tell |
36 | | -general storage and authentication tokens apart. Persistent cookies have an expiry |
37 | | -function which could serve as an automatic inactivity logout mechanism whereas web |
38 | | -storage such as IndexedDB doesn’t even have an expiry functionality. |
39 | | - |
40 | | -## Straw Man Proposal |
41 | | - |
42 | | -Below we present a straw man proposal for how a web API for logged in status could look |
43 | | -and work. This is a starting point for a conversation, not a fully baked proposal. |
44 | | - |
45 | | -### API |
46 | | - |
47 | | -Here’s how the API for setting IsLoggedIn to true could look: |
48 | | - |
49 | | -``` |
50 | | -navigator.setLoggedIn( |
51 | | - username: non-whitespace string of limited length, |
52 | | - credentialTokenType: “httpStateToken” OR “legacyAuthCookie”, |
53 | | - optionalParams { } |
54 | | -) –> Promise<void> |
55 | | -``` |
56 | | - |
57 | | -The returned promise would resolve if the status was set and reject if not. The API could |
58 | | -potentially take an expiry parameter but here we’re assuming that a designated |
59 | | -[HTTP State Token](https://mikewest.github.io/http-state-tokens/draft-west-http-state-tokens.html) |
60 | | -or “legacy auth cookie” manages the expiry of the login through their own mechanisms. |
61 | | - |
62 | | -Here’s how the API for setting IsLoggedIn to false could look: |
63 | | - |
64 | | -``` |
65 | | -navigator.setLoggedOut(optionalUsername) –> Promise<void> |
66 | | -``` |
67 | | - |
68 | | -The optional username parameter highlights that we might want to support concurrent logins |
69 | | -on the same website which would require the site to keep track of who to log out and |
70 | | -credential tokens to be scoped to user names. |
71 | | - |
72 | | -Here’s how the API for checking the IsLoggedIn status could look: |
73 | | - |
74 | | -``` |
75 | | -navigator.isLoggedIn() –> Promise<bool> |
76 | | -``` |
77 | | - |
78 | | -This last API could potentially be allowed to be called by third-party iframes that do not |
79 | | -currently have access to their cookies and website data. The iframes may want to render |
80 | | -differently depending on whether the user is one of their logged in customers or not. |
81 | | - |
82 | | -### Defending Against Abuse |
83 | | - |
84 | | -If websites were allowed to set the IsLoggedIn status whenever they want, it would not |
85 | | -constitute a trustworthy signal and would most likely be abused for user tracking. We must |
86 | | -therefore make sure that IsLoggedIn can only be set when the browser is convinced that |
87 | | -the user meant to log in or the user is already logged in and wants to stay logged in. |
88 | | - |
89 | | -Another potential for abuse is if websites don’t call the logout API when they should. |
90 | | -This could allow them to maintain the privileges tied to logged in status even after the |
91 | | -user logged out. |
92 | | - |
93 | | -There are several ways the browser could make sure the IsLoggedIn status is trustworthy: |
94 | | - |
95 | | -* Require websites to use WebAuthn or a password manager (including Credential Management) |
96 | | -before calling the API. |
97 | | -* Require websites to take the user through a login flow according to rules that the |
98 | | -browser can check. This would be the escape hatch for websites who can’t or don’t want to |
99 | | -use WebAuthn or a password manager but still want to set the IsLoggedIn bit. |
100 | | -* Show browser UI acquiring user intent when IsLoggedIn is set. Example: A prompt. |
101 | | -* Continuously show browser UI indicating an active logged in session on the particular |
102 | | -website. Example: Some kind of indicator in the URL bar. |
103 | | -* Delayed browser UI acquiring user intent to stay logged in, shown some time after the |
104 | | -IsLoggedIn status was set. Example: Seven days after IsLoggedIn was set – “Do you want to |
105 | | -stay logged in to news.example?” |
106 | | -* Requiring engagement to maintain logged in status. Example: Require user interaction as |
107 | | -first party website at least every N days to stay logged in. The browser can hide instead |
108 | | -of delete the credential token past this kind of expiry to allow for quick resurrection of |
109 | | -the logged in session. |
110 | | - |
111 | | -### Credential Tokens |
112 | | - |
113 | | -Ideally, a new IsLoggedIn API like this would only work with modern login credentials. |
114 | | -HTTP State Tokens could be such a modern piece. However, to ensure a smooth path for |
115 | | -adoption, we probably want to support cookies as a legacy option. |
116 | | - |
117 | | -Both HTTP State Tokens and cookies would have to be explicitly set up for authentication |
118 | | -purposes to work with IsLoggedIn. In the case of both of these token types, we could |
119 | | -introduce an __auth- prefix as a signal that both the server and client consider the user |
120 | | -to be logged in. Or we could allow HTTP State Token request and response headers to convey |
121 | | -login status. Note that sending metadata in requests differs from how cookies work. |
122 | | - |
123 | | -The expiry of the token should be picked up as a logout by IsLoggedIn. |
124 | | - |
125 | | -Cookies have the capability to span a full registrable domain and thus log the user in to |
126 | | -all subdomains at once. HTTP State Tokens have a proper connection to origins but can be |
127 | | -declared to span the full registrable domain too. We should probably let the credential |
128 | | -token control the scope of the IsLoggedIn status. |
129 | | - |
130 | | -Explicitly logging out should clear all website data for the website, not just the |
131 | | -credential token. The reverse, the user clearing the credential token (individually or as |
132 | | -part of a larger clearing of website data), should also log them out for the purposes of |
133 | | -IsLoggedIn. |
134 | | - |
135 | | -### Federated Logins |
136 | | - |
137 | | -Some websites allow the user to use an existing account with a federated login provider to |
138 | | -bootstrap a new local user account and subsequently log in. The IsLoggedIn API needs to |
139 | | -support such logins. |
140 | | - |
141 | | -First, the federated login provider needs to call the API on its side, possibly after the |
142 | | -user has clicked a “Log in with X” button: |
143 | | - |
144 | | -``` |
145 | | -navigator.initiateLoggedInFederated(destination: secure origin) –> Promise<void> |
146 | | -``` |
147 | | - |
148 | | -For the promise to resolve, the user needs to already have the IsLoggedIn status set for |
149 | | -the federated login provider, i.e. the user needs to be logged in to the provider first. |
150 | | - |
151 | | -Then the destination website has to call the API on its side: |
152 | | - |
153 | | -``` |
154 | | -navigator.setLoggedInFederated( |
155 | | - loginProvider: secure origin, |
156 | | - username, |
157 | | - credentialTokenType, |
158 | | - optionalParams { } |
159 | | -) –> Promise<void> |
160 | | -``` |
161 | | - |
162 | | -The promise would only resolve if the `loginProvider` had recently called |
163 | | -`setLoggedInFederated()` for this destination website. |
164 | | - |
165 | | -## Challenges and Open Questions |
166 | | - |
167 | | -* __Grandfathering__. Some websites may not want to prompt an already logged in user or |
168 | | -take them through an additional login flow just to set the IsLoggedIn status. |
169 | | -* __Expiry limit__. What is a reasonable limit for expiry without revisit/re-engagement? |
170 | | -* __Single sign-on__. If the browser supports |
171 | | -[First Party Sets](https://github.com/krgovind/first-party-sets), it may support single |
172 | | -sign-on within the first party set, for instance with an optional parameter |
173 | | -includeFirstPartySet: [secure origin 1, secure origin 2]`. The browser would check the |
174 | | -integrity of the first party set claim and potentially ask the user for their intent to |
175 | | -log in to multiple websites at once before setting the IsLoggedIn status for all of them. |
176 | | -The expiry of the login status for the first party set would likely be controlled by the |
177 | | -expiry of the credential token for the single sign-on origin. However, there is not |
178 | | -browser agreement on how to support First Party Sets in a privacy preserving way (see |
179 | | -[Issue 6](https://github.com/krgovind/first-party-sets/issues/6) and |
180 | | -[Issue 7](https://github.com/krgovind/first-party-sets/issues/7)). |
181 | | - |
182 | | -## Feedback Received |
183 | | - |
184 | | -You can read the IsLoggedIn email conversation on the W3C WebAppSec WG mailing list |
185 | | -[here](https://lists.w3.org/Archives/Public/public-webappsec/2019Sep/0004.html). |
186 | | - |
187 | | -You can read the IsLoggedIn meeting minutes from W3C TPAC 2019 |
188 | | -[here](https://github.com/w3c/webappsec/blob/master/meetings/2019/2019-09-TPAC-minutes.md#isloggedin). |
189 | | - |
190 | | -Below is a summary of the feedback we've received so far. For most of it, the intent is |
191 | | -"IsLoggedIn should take this additional scenario into account." |
192 | | - |
193 | | -### Remembered Device |
194 | | -Some sites remembers the browser even after a logout and has a lower bar for login after |
195 | | -that point. For instance banks that require users to be logged in to do transactions and |
196 | | -then log inactive users out fairly quickly. The lower bar for re-login is used for e.g. |
197 | | -fraud mitigation. [John's response at TPAC:] We don't have to wipe all storage |
198 | | -and state on logout. From the point of logout, the same storage expiry can apply as for a |
199 | | -casual visit. |
200 | | - |
201 | | -### Use the Term Bucket |
202 | | -Storage folks are talking about expiring [buckets](https://storage.spec.whatwg.org/#bucket) |
203 | | -of storage, a bit of storage inside an origin. We should possibly reason about buckets and |
204 | | -the expiry of them rather than cookies and IndexedDB. |
205 | | - |
206 | | -### Multi-Login and Multiple User Profiles |
207 | | -The user may have multiple accounts for one website, multiple users may be using the same |
208 | | -browser to log in to a specific website (shared device case), and some websites allow |
209 | | -multiple concurrent logins with fast profile switching. In the case of multiple concurrent |
210 | | -logins, there may be a dominant or operating account among them. |
211 | | - |
212 | | -### Auto-Complete for SMS Codes Could Be Signal of Login |
213 | | -In addition to the use of WebAuthn or a password manager, auto-complete of an SMS code |
214 | | -may also be a trustworthy signal of the user logging in. |
215 | | - |
216 | | -### Link-Based Login |
217 | | -Both account recovery flows and so called password-less logins may use links with |
218 | | -authentication tokens in them. A tap or click logs the user in as long as the token is |
219 | | -valid. |
220 | | - |
221 | | -### Websites May Not Like Managed Logins |
222 | | -If websites need their users to adopt managed logins such as password managers and |
223 | | -WebAuthn to get the privileges that come with IsLoggedIn, we would be pushing users into |
224 | | -the risks that may be involved in using managed logins. There are websites that want to |
225 | | -have an exclusive relationship with their users that the browser and its extensions are |
226 | | -not involved in, and there are users who prefer to memorize or physically write down |
227 | | -their passwords. |
228 | | - |
229 | | -### Federated Login Functionality Needed? |
230 | | -Couldn't a website that leverages federated logins just set its IsLoggedIn status after |
231 | | -the federated login flow has completed? Why all the extra functionality? |
232 | | - |
233 | | -### IsLoggedIn Could Be Used In the Storage Access API |
234 | | -[The Storage Access API](https://github.com/privacycg/storage-access) is intended to allow |
235 | | -authenticated embeds. IsLoggedIn status could be used in conjunction with the Storage |
236 | | -Access API, for instance in relaxing some of the scoping restrictions with the Storage |
237 | | -Access API. IsLoggedIn could also become a requirement for being granted storage access |
238 | | -as third-party. |
239 | | - |
240 | | -### Could Site Engagement Serve the Same Purpose? |
241 | | -Chrome uses something called [Site Engagement](https://www.chromium.org/developers/design-documents/site-engagement) |
242 | | -to understand which websites the user uses a lot. Could that signal be used to address |
243 | | -the concerns about "logged in by default" and storage space? |
244 | | - |
245 | | -One potential problem is that Site Engagement scores are neither accessible to websites |
246 | | -nor possible to set. It's an opaque thing from a developer perspective. |
247 | | - |
248 | | -### IsLoggedIn Privileges May Push Sites to Mandate Login |
249 | | -The privileges that may be associated with IsLoggedIn may incentivize websites to mandate |
250 | | -logins. Such a result may not be beneficial for user privacy since PII is often involved |
251 | | -in logging in. |
252 | | - |
253 | | -### Successful Logins Hard to Detect |
254 | | -Since only the server truly knows whether or not a login was successful, it may turn out |
255 | | -to be hard to detect successful logins. |
| 1 | +# [IsLoggedIn](https://github.com/privacycg/is-logged-in) has moved to the Privacy CG. |
0 commit comments