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
{{ message }}
This repository has been archived by the owner on Apr 28, 2020. It is now read-only.
Automatic scope and top level domain cookies introduced via #166 and #168 have greatly improved user management for apps sharing a parent domain. However, apps hosted on other domains still depend on the primitive login beacon framework from #52, which interrupts the user experience and won't work for anonymous users (as per #146).
The login beacon iframe should now redirect to /login with an additional parameter, a signed statement that is equivalent to the lastuser cookie. The client app can verify the statement using a shared secret and choose to accept it without redirecting the user, instead just reloading the page or updating it in-place (especially for an anon user where nothing will change on reload, only that their session cookie will be updated accordingly).
Since the login beacon's code will allow this cookie-equivalent's content to be read by JavaScript, it can't use the same secret key as the cookie (since the purpose is to prevent JS from acquiring a cookie for replay attacks). We'll need a different secret key, possibly one that is app unique.
One option is to use the SHA256 sum of the app's client secret (identified by the client_id presented when loading the login beacon page). Lastuser only keeps this SHA256 sum and the client app can easily calculate this from its copy of the secret key.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Automatic scope and top level domain cookies introduced via #166 and #168 have greatly improved user management for apps sharing a parent domain. However, apps hosted on other domains still depend on the primitive login beacon framework from #52, which interrupts the user experience and won't work for anonymous users (as per #146).
The login beacon iframe should now redirect to /login with an additional parameter, a signed statement that is equivalent to the
lastuser
cookie. The client app can verify the statement using a shared secret and choose to accept it without redirecting the user, instead just reloading the page or updating it in-place (especially for an anon user where nothing will change on reload, only that their session cookie will be updated accordingly).Since the login beacon's code will allow this cookie-equivalent's content to be read by JavaScript, it can't use the same secret key as the cookie (since the purpose is to prevent JS from acquiring a cookie for replay attacks). We'll need a different secret key, possibly one that is app unique.
One option is to use the SHA256 sum of the app's client secret (identified by the client_id presented when loading the login beacon page). Lastuser only keeps this SHA256 sum and the client app can easily calculate this from its copy of the secret key.
The text was updated successfully, but these errors were encountered: