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

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!

View
 

Details-of-UX-Best-Practices-for-OPs

Page history last edited by Allen Tom 14 years, 10 months ago


Overview

We RECOMMEND that OPs support login and consent pages that fit in a small popup browser window as specified in the OpenID UI Extension, which will be displayed on top of the RP's page. There are three kinds of pages the OP might want to show the user:

  1. The Login Page
  2. Consent Page
  3. Account Linking Page (settings for Automatic Login / checkid_immediate)

 

Login Page

The general layout of the Login Page is as follows (subject to change):

 

Elements to show on the OP's Login Page

 

  • The URL of the browser's address bar MUST clearly display the OpenID Provider's domain
  • OpenID Provider's name, Relying Party's name
  • Explaination of what is happening (data sharing description)
  • Username / Password
  • Checkbox to enable Automatic Login for the RP (checkid_immediate)
  • Continue / Cancel buttons
  • Link to Account Recovery for forgotten passwords
  • Legalese / ToS

 

 

When to Show the Login Page

Generally, it is preferable to show the Consent Page over the Login Page, since users don't have to type their user id and password in the Consent Page. There are, however, some instances in which an OP may decide to show the Login Page:

 

Consent Page

The general layout of the Consent Page is as follows (subject to change):


 

  • OpenID Provider's name, Relying Party's name
  • Explaination of what is happening (data sharing description)
  • Username of user currently logged into the OP
  • Option to login as a different user
  • Checkbox to enable Automatic Login for the RP (checkid_immediate)
  • Continue / Cancel buttons
  • Link to Account Recovery for forgotten passwords
  • Legalese / ToS

When to Show the Consent Page

The Consent Page is shown in two different circumstances:

  • When the OP determines that no fresh authentication of the user is necessary. In this case, the Consent Page is the only page the user will see in the popup window.
  • When the OP showed the Login Page, and determined that further communication with the user is necessary in order to properly explain to the user what's happening. In this case, the user will see first the Login Page, and then the Consent Page.

 

Popup Resizing

To prevent overwhelming the user, OpenID Providers are encouraged to briefly and concisely explain to the user what happening. Users who want additional information should have the option to find out more about what is going on.  OpenID Providers MAY want to dynamically resize the Login/Consent pages to display additional information if needed.

 

OpenID Providers may need to resize the Login screen to display a CAPTCHA or to display more information as needed.

 

Example of the dynamically resized login screen after the user clicked on "What am I sharing?"

 

 

Account Linking Screen

 

Users may want to supress the consent screen for future visits to the Relying Party by checking on the "Automatically Sign me in to Relying Party" checkbox, enabling checkid_immediate mode. OpenID Providers MUST give users an option to disable Automatic Sign-in in their Account Management screens.

 

The Account Linking screen should display all Relying Parties that have checkid_immediate enabled.

 

OpenID Providers that also support OAuth for data access MAY want to combine checkid_immediate preferences with OAuth Access Token management, to allow users to disable checkid_immediate and to revoke OAuth Access tokens on a single screen.

 

 

 

Page Layout

Site Name

This section of the page should identify, with clear branding, the OP to the user.

What is Happening

Here we explain to the user in general terms what's about to happen. Proposed Language

  • (for the case in which the RP simply requests OpenID authentication, without requesting user attributes or OAuth tokens): "Sign in to RelyingParty.com with your OpenID Provider account."
  • (for the case in which the RP requests additional access, such as user attributes or OAuth tokens): "Connect RelyingParty.com with your OpenIDProvider account."

This section should also show the branding of the RP and OP, and graphically suggest to the user what's happening

Options

This section is optional. It may be in the Login Page, the Consent Page, both, or neither. In this section the OP explains in more detail what access the user is granting to the RP. While we RECOMMEND that the RP's request is presented to the user as a yes/no proposition, the Options section is where the OP would like the user modify the response (e.g. only allow read-only access, opt-out of attribute sharing, etc.)

This section SHOULD not be more than 5 lines of text at 450 pixels of window width.

User ID/Password (Login Page Only)

This is where the OP puts their login box, branded to look like the login box users are used to seeing on the OP's main login page.

Legalese

Proposed text (would have to be approved by OPs legal department):

  • (for the case in which the RP does not request OAuth access): "RelyingParty.com is not owned, operated, or controlled by IdentityProvider.com. <a href=...>Learn more</a>"
  • (for the case in which the RP requests OAuth access): "You can always change your approval settings on the My Account page. RelyingParty.com is not owned, operated, or controlled by IdentityProvider.com. <a href=...>Learn more</a>"

Ok/Cancel Buttons

Proposed text:

  • (for the case in which the RP simply requests OpenID authentication, without requesting user attributes or OAuth tokens): "Sign in"/"Cancel"
  • (for the case in which the RP requests user attributes, but no OAuth tokens): "Share"/"Cancel"
  • (for the case in which the RP requests OAuth tokens): "Connect"/"Cancel"

UX Flow

When the OP receives an auth request with the openid.ux=popup parameter, it SHOULD display its popup UI.

From the request, it should determine whether it should display only the Login Page, only the Consent Page, or both (one after the other).

  • If the user cancels on the login page, the OP MUST simply close the window.
  • If the user signs in on the login page, and no Consent Page needs to be shown, the OP SHOULD redirect to the RP's return_to URL (with a success state).
  • If the user signs in on the login page, and a Consent Page needs to be shown, the OP will show the Consent Page next.
  • If the user approves on the Consent Page, the OP SHOULD redirect to the RP's return_to URL (with a success state).
  • If the user cancels on the Consent Page, the OP MUST do one of two things:
    • redirect to the RP's return_to URL (with a failure status) - this is RECOMMENDED; or
    • simply close the window.

When the OP receives an auth request without the openid.ux=popup parameter, it SHOULD display a UI, and handle user actions, in a way suitable for the full-frame redirect flow.

Security Considerations

The OP SHOULD insert frame busting code into its Consent Page, and MAY also insert frame busting code into its Login Page. The Login

 

OpenID Popup Support

 

OpenID Providers SHOULD implement the OpenID Popup UI as defined in the OpenID UI Extension

 

 

 

Comments (0)

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