- OpenID User Interface Extension 1.0 (including the ability to display the favicon of the website)
- x-has-session, which is an enhacement to checkid_immediate requests via the UI extension. If the request includes "openid.ui.x-has-session," it will be echoed in the response only if Google detects an authenticated session
- Support for the US Government's GSA profile for OpenID
- PAPE (Provider Authentication Policy Extension) to support forced password reprompts
- Support for not only Google Accounts, but also our Google Apps customers, as discussed on the Enterprise blog
For more details, please refer to our OpenID documentation.
While these technologies are all standards-based, the methods for how to combine them to achieve this success rate are not obvious, and took a while for the industry to refine. More information is available in the Hybrid Onboarding Guide, but below is a quick summary of some of the best practices for this hybrid onboarding technique:
- The technique is primarily for websites with an existing login system based on email addresses.
- It also assumes the website will send email to users who are not yet registered, whether it is through traditional email marketing or social network invitations.
- The website owner then needs to choose a small set of email providers such as Yahoo and Google that support these standards.
- Whenever the website sends email to a user at one of those providers, any hyperlinks that promote registration at the website should be modified to communicate the email address (or at least domain) of the user back to the website's registration page.
- If the registration page detects a user from one of these domains, it should NOT start the traditional process of asking the user to enter a password, password confirmation, and email. Instead, it should prominently show a single button that says "Sign up with your Google Account" — where Google is replaced with the name of the email provider.
- If the user clicks that button, the website should use the OpenID protocol to ask the email provider to authenticate the user, provide their email address, and optionally ask for access to their address book using the hybrid OpenID/OAuth protocol and the Portable Contacts API. More details about this flow are available on the OpenID blog.
- Once the user returns to the website, it can create an account entry for the user. The website can also mark the email address as verified without having to send a traditional "email verification" link to the user. If the website received the user's permission to access their address book, it can now download it and look for information about the user's friends.
- In the unusual case where an account already exists for that email address, the website can simply log the user into that pre-existing account.
- For any newly registered user, the website should then display a page that confirms the user is registered and that indicates how they should sign in in the future.
- To make the login process simple, the website should modify their login box to include a logo for each of the trusted email providers it supports, or use one of the other user experiences for Federated Login.
- If a user clicks the email provider button, they can again be sent to that provider's site using the OpenID protocol. When the user comes back, the website can either detect that they previously registered, or if it is a new user, the website can create an account for them on the fly.
- In some cases the account may already exist for that email address, but it was not initially registered using OpenID. In that case, the website can simply log the user in to that pre-existing account.
sweat ^^
ReplyDelete1ะน/x
ReplyDelete