junosuarez / web-login

A maximally minimal proposal for browser-based user identity management
44 stars 6 forks source link

navigator.login idempotent? login/logout? #3

Closed junosuarez closed 10 years ago

junosuarez commented 10 years ago

If navigator.login() is called multiple times, is the same promise returned? This creates, effectively, a memoized page-context "logged in" state. navigator.logout() would clear this state. Subsequent calls to navigator.login() would trigger the authentication UI flow again in the browser.

Another thought is to have no state at all captured in navigator.login(), and each call would trigger the login flow. It would then be up to the application to

  1. only call navigator.login() once to avoid annoying the user
  2. save the ID token in whatever session management the application chooses, eg a cookie, or otherwise use the token to start a session using whatever other sessionID system there is or whatever.
webdesserts commented 10 years ago

The only issue that I could think of is if for some reason an application allowed you to "login" with multiple users (similar to gmail). If navigator.login() returned the same promise this would limit the user to a single session at a time.

I think navigator.login() should always return a new promise and token.

dporru commented 10 years ago

The application probably has to check the validity of the token with the server. So it had to store if this check was successful. It makes sense to go for the second option then. A call to navigator.login() gives a new token that you have to check again, once comfirmed you store somewhere that user is logged in and the token is valid.

junosuarez commented 10 years ago

@dporru to clarify, the javascript application in the browser would post this token to a server, just as it would with a username / password. Then, the server would match it with a user and (probably) create some sort of session and manage state that way. For security reasons, the token should not be stored locally, or anywhere you wouldn't store any other set of credentials.

The server-side application would have no need to verify the credentials with a 3rd party, since the token returned by navigator.login() would be unique to that (user identity, domain) vector.

The proposal is made simpler by not storing state on the page. Unless and until someone raises a use case which would require otherwise, the proposal will be to request the login information from the user anew (and to return a new promise) each time navigator.login() is called. It will be up to the JavaScript application on the page to ensure that navigator.login() is only called as many times as necessary. Since there is no "logged in state" from the point of view of the browser, there is no need for navigator.logout().

An example of when a page may call navigator.login() more than once: If a user is registering for a new service and wants to associate identities from more than one provider, they could click "add identity" for each IDP they wish to use.