Implement Select Provider popup window capability

[dmitrizagidulin]

If the app developer doesn't provide their own 'select provider' UI, it would be helpful if calling login() without passing in an IDP would open a Select Provider popup.

There's two workflow options for this popup window that we have to decide between -- either 1) it serves as a select provider UI only, and it's the main app window that redirects for the OAuth dance. Or 2) The redirect happens in the popup window, which is more convenient for the app developer, but involves more moving parts to implement.

Recommendation: We can start with implementing Option 1, since that's the easiest, and discuss the next steps.

Option 1 - Popup is Select Provider Only, Main App Window Redirects

pro: Implementing this requires less moving parts.

con: More inconvenient for the app developer; the user can potentially lose their place in the page after the resulting redirect (for some single-page js apps, like Tabulator).

Workflow:

1. main window: login() is called with no IDP, popup window is opened, shows a list of IDPs (plus at least a textbox for user to enter their own domain or webid or preferred provider).
2. popup: User clicks on a provider (or enters a url in the textbox), popup window sends a postMessage() event to the opener (main app window) with the url of the selected provider and closes itself.
3. main window: Main window (the auth client) receives the providerSelected event, loads the RP client config for that IDP, constructs the /authorize URL, and redirects itself to login.
4. main window: User logs in. When the IDP redirects the user to the post-login redirect_uri (usually the same URI as the main app was), the app logic calls authClient.currentSession() on page load, which results in the auth client parsing the callback uri and extracting the credentials from it, as usual.

Sample code snippets:

var selectProviderWindow
// providerSelectPopupSource is a string that contains the HTML + JS of the popup window

initEventListeners()

if (selectProviderWindow) {
  // Popup has already been opened
  selectProviderWindow.focus()
} else {
  // Open a new Provider Select popup window
  selectProviderWindow = window.open('',
    'selectProviderWindow',
    'menubar=no,resizable=yes,width=400,height=400'
  )

  selectProviderWindow.document.write(providerSelectPopupSource)
  selectProviderWindow.document.close()  // important
}

function initEventListeners() {
  window.addEventListener('message', function (event) {
    switch (event.data.event_type) {
      case 'providerSelected':
        dispatchProviderSelected(event.data.value)  // provider uri

        break
      default:
        console.error('unknown event type: ', event)

        break
  })
}

In the popup window:

// opener is a browser global
function selectProvider (providerUri) {
  console.log('Provider selected: ', providerUri)
  
  var message = {
    event_type: 'providerSelected',
    value: providerUri
  }

  opener.postMessage(message, opener.window.location.origin)
  // close yourself
  window.close()
}

Option 2 - Popup is Select Provider + Redirect to Login, Main Window Not Redirected

pro: More convenient for the app developer (user's place / workflow in the main app page is not interrupted).

con: More moving parts to implement (would require alteration to solid-server & config).

Workflow:

1. main window: Decide on the callback redirect_uri during RP dynamic registration (see the callback uri discussion below).
2. main window: login() is called with no IDP, popup window is opened, shows a list of IDPs (plus at least a textbox for user to enter their own domain or webid or preferred provider).
3. popup: User clicks on a provider (or enters a url in the textbox), popup window sends a postMessage() event to the opener (main app window) with the url of the selected provider, and stays open.
4. main window: Main window (the auth client) receives the providerSelected event, loads the RP client config for that IDP, constructs the /authorize URL, and redirects the popup window to login.
5. popup: User logs in. When the IDP redirects the popup to the post-login redirect_uri, some logic in the redirect_uri page must do a postMessage to the opener (main app page) with its own uri (containing hash fragments with credentials), and closes itself. (See the discussion below).
6. main window: Receives the authCallback event from the popup window, with the callback uri as the event payload. Extracts the credentials from that uri, as usual (instead of currentSession deriving them from the main page's own current uri).

The tricky bit is step 5. What should be the redirect_uri that the RP client pre-registers, and asks to be redirected to during the authentication workflow? There's basically 3 options:

1. The rp client uses its own URI as a redirect_uri (like it currently does). In order for this to work, though, the main app code needs to have a snippet like:

   // in the 'onload' window event
   if (opener) {
     opener.postMessage({ event_type: 'authCallback', value: window.location.href }, opener.window.location.origin)
     window.close()  // close yourself
   }

   as soon as the page loads (so that the full app doesn't load in the popup window).

2. The app developer includes a callback.html (see below) as part of their web application, and tells the RP to register it as the redirect_uri.

3. We include a callback.html in the /common/ folder of all node-solid-server installations, and advertise the callback_uri endpoint either via a Link rel header, or via a service config document. The RP discovers this uri, and includes it in the redirect_uris list during dynamic registration.

Sample callback.html:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta http-equiv="Content-type" content="text/html;charset=utf-8">
  <script type="text/javascript">
    window.addEventListener('load', function () {
      var callbackUrl = window.location.href
      var opener = window.opener
      var pageOrigin = opener.location.origin

      var message = {
        event_type: 'authCallback',
        value: callbackUrl
      }

      opener.postMessage(message, pageOrigin)
      window.close()
    })
  </script>
</head>
<body>
<h1>Login successful</h1>

<p>Please close this window.</p>
</body>
</html>

[timbl]

I feel it is clear from earlier discussions that, while option 1 may be useful for testing, the functionality required in for example solid-ui, as used by existing apps, is to be able to maintain app state and stack during login process. The functionality the app requires "get the user to [sign up and] sign in and call me back when they have". This needs Option 2. This is what is needed for solid-app-set panes. This is what all kinds of alls will find useful, though we agreed there are apps, like banking apps, where the stack and very little state is not preserved between logged out and logged in states.

We need to be able to provide prompts like

• Log in to be able to use this app
• Log in to be able to view this thing
• Log in to see more stuff
• Log in to be able to edit
• Log in to be able to participate

which then are replaced by the UI to do the things described. But the view could be a view embedded within another view with many other subviews with different state, which we don't want to lose with a top-level redirect.

I thought there are examples around which do this. Basically the redirect happens in the iframe, and the credentials get passed back to the parent one way or another.

[timbl]

For the 3 options in step 5 above ...

Option 1 puts a constraint on any top-level app using this to be able double as a login destination page. It is a weird thing for the development process to have to guarantee, and for devs to remember. This seems like bad design because it is abusing the page. One can imagine the bowser starting to load the huge tree of resources the page normally has only to have the page kill itself. No way to treat a browser.

Option 2 seems reasonable, in that a developer just has to have access to a public page somewhere which will be secure from write and public for read. (Assuming there is no constraint on the domain). We could use fobar.github.io/fixed/loginSuccess.html . It would have to be secure, though.

Option 3 would work -- you are string though from the server of the app, or the data? Whoever it is has to be very trustworthy.

Suppose we do: Option 2 if the app passes it in, else fallback to option 3, else fall back to a fixed redirect page solid.mit.edu/fixed/loginok.html with a console.warning() that you are just testing and the fixed one won't scale.

(An interesting property of this is that we know the contents of the thing in advance -- if it was a HTML link we could use hash with https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity)

(It is almost as though a data: URL is called for. Let's assume that browsers will not do those)

[dan-f]

Just an update from my end.

I am working on the desired workflow - redirects within the popup.

As for the callback URI - this has to be considered with security in mind. Since the UX demands that all redirects happen within the popup, the popup must use postMessage to communicate back with the parent application. For security reasons, it's important to specify the targetOrigin. A static application hosted on a solid server will not be able to know the application origin.

I am moving forward with implementing the provider select / callback application(s) as distinct HTML app bundles which can be built and bound to specific application origins so that postMessage is secure.

[dmitrizagidulin]

targetOrigin from the popup can be gotten from opener.window.location.origin (since the popup is generated by the app itself, in js).

[dan-f]

And if a malicious domain opens your popup, then whoops!

[dmitrizagidulin]

The popup mechanism relies on the user verifying the url in the popup's url bar (to make sure that it wasn't opened from a malicious domain). Can't really get around that.

[dan-f]

That's a separate issue.

The point of specifying targetOrigin when communicating to a parent window is to verify your assumption that the parent window is in fact running on the domain you think it is.

[dan-f]

Fixed in #24