• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Stop wasting time looking for files and revisions. Connect your Gmail, DriveDropbox, and Slack accounts and in less than 2 minutes, Dokkio will automatically organize all your file attachments. Learn more and claim your free account.



Page history last edited by steven jackson 11 years, 3 months ago

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:

  • email validation: the user enters an email address on the RP site, and the RP uses an OpenID (+AX/Sreg) flow to have the email address validated by the user's OP.
  • URLs-as identities: certain communities use URLs as identities (e.g., bloggers). It makes sense for the RP to provide a text field in which the user can type their identity.
  • as a fallback: in a case in which the user's OP cannot be determined by the RP (see below), the RP might have to show a text field for the user to input hsi/her OP/URL/XRI/email address (some information that would allow the RP to kickstart the OpenID flow). 

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:

  • a cookie the RP set on the user last time they logged in
  • from context (e.g., the user landed on the RP's page after clicking on a link that was sent to their ...@yahoo.com email address)
  • through some yet-to-be-defined browser extension that signals to the RP the user's OP preferences
  • through some yet-to-be-defined service that allows the RP to learn the user's OP preferences (see, for example, this proposal). 

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

  • It can display a small number of differently-branded Login Buttons that correspond to the most-frequently used OPs at the RPs site.
  • It use a login box that Collects User Input (see above), for example, the user's email address, and use the "Collecting User Input" flow above
  • It can use a combination of the two.  

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

  • The OP endpoint URL
  • Association handles negotiated between teh RP and the OP
  • AX attributes that the RP is requesting
  • OAuth scopes that the RP is requesting 

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:

  • If the auth response validates, set a login cookie on the HTTP response sent back to the popup.
  • Associate user attributes contained in the auth response with the user.
  • Possibly exchange the OAuth request token contained in the auth response for an OAuth access token, and associate with the logged-in user. (This step can be omitted if the RP, now knowing the identity of the user, realizes that it already possesses an appropriate OAuth token for that user.)

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.

Comments (0)

You don't have permission to comment on this page.