Details-of-UX-Best-Practices-for-RPs



Launching Sign-In

There are two ways the RP can launch the sign-in process:

  1. By collecting a user-supplied id of the OP or user (e.g., through a text box)
  2. By providing a button ("click here to sign in") for the user.

We'll look at these in more detail below: 

Collecting User Input 

Use Cases

Providing a text box in which the user enters his/her id, or the id of his/her OP might make sense in the following use cases:

UX Flow

 

Example UX Flows and UIs

 

 

After the user inputs their identifier, we RECOMMEND that the RP do the following:

  1. Send an XHR request to the RP's server with the user-supplied information.
  2. On the server, perform OpenID discovery on the user-supplied information.
  3. Return the discovery results, along with other data necessary to send the user to the OP, to the user agent. This information may include, among other things:
    • The OP endpoint URL
    • Association handles negotiated between the RP and the OP
    • AX attributes the RP is requesting
    • OAuth scopes the RP is requesting
  4. Construct a valid OpenID auth request, which is a URL at the OP endpoint.
  5. At this point, the UX flow continues identically to the UX flow in the "Login Button" category. 

Login Button

Use Cases 

Showing a login button elimates the need for the user to type their own id/their OPs id into the RP. It is therefore preferable to the method of Collecting User Input (see above), with the exception of the use case in which users/RPs need to make use of OpenID claimed identities. Login Buttons only work with directed identities.

If the RP can determine the user's OP, we RECOMMEND that the RP prominently display a Login Button that shows the branding of that user's RP (e.g., "Log in with your Google Account"). The RP MAY also display, less prominently, Login Buttons for other OPs and/or text fields for Collecting User Input (see above). Examples of how one can determine the user's OP:

If the RP cannot determins the user's OP, the RP has a number of options:

UX Flow

When rendering a Login Button, the server can perform discovery for the OP in question before the Login Button is rendered. The onclick-handler of the Login Button thus can already be pre-loaded with information such as

This is enough information to:

  1. Construct a valid OpenID auth request, which is a URL at the OP endpoint.
  2. Open a popup window, and point it to the URL of the OpenID auth request.
    • The popup window SHOULD be 450 pixels wide, and 400 pixels high
    • The popup window MUST be resizable be the OP
    • The popup window MUST show the address bar.
    • The popup window SHOULD try to minimize all other decorations, such as bookmark bars, etc

Note that the OpenID auth request URLs can be very long. If OpenID auth GET request exceeds 2KB, we RECOMMEND that the RP instead open a popup window to a page on the RP itself, which then POSTs the OpendID auth request to the OP inside the popup.

  1. Adjust the UI on the underlying page accordingly (e.g., wash out the page)
  2. Poll periodically (every 50ms..100ms) whether the popup window is closed.
  3. Once the popup window is closed, send an XHR request to the server. This XHR request will carry the user's login cookie if and only if the OpenID login succeeded in the popup window.
  4. Adjust the UI on the RP's page, depending on the result of the XHR request (which presumably will depend on the presence of the login cookie).

 

Account linking for legacy users

 

Users signing into an RP using OpenID may already have an existing account on the RP's site. If the RP believes that the user already has a legacy account, the RP should prompt the user to link the OpenID with the legacy account.

 

RPs may attempt to use the user's email address to determine if the user already has a legacy account in their user database with the same email address. RPs MUST verify the user's identity using the legacy authentication system (verify the password) to ensure that the user signing in with OpenID is actually the legacy account holder.

 

 

Manage My OpenIDs

 

Relying Parties should give users the ability to add and remove OpenIDs from their account, similar to how sites allow users to manage their email addresses.

 

Processing Auth Responses

The OP will return, upon user consent, the user agent (in the popup) to the RP. This auth response arrives at the RP in form of a GET or POST request, issued by the user agent in the popup. Before responding to this request, the RP SHOULD perform the following steps:

Then, the RP SHOULD serve a document to the popup that simply closes the window (this will have the effect of setting the login cookie). 

Discovering Popup Support

Not all OPs will have UIs that are suitable for inclusion in a small popup window, or implement flows that guarantee that the popup window will close at the end of the interaction (e.g., currently Yahoo!'s OP redirects the user to their homepage when the user does not approve the auth request). Therefore, it is important that the RP discover whether or not the OP support the Popup-style UX flows described above. If the OP does not signal support for the Popup-style UX flows, the RP SHOULD use a traditional full-page redirect flow. 

 

OpenID Providers supporting the Popup UI SHOULD advertise their support by implementing OpenID Discovery as defined in the OpenID UI Extension.