Création des Logiciels de gestion d'Entreprise, Création et référencement des sites web, Réseaux et Maintenance, Conception
seo User Experience in the Identity Community 2013
Seo Master present to you: By Eric Sachs and Ben Laurie, Google Security Team
One of the major conferences on Internet identity standards is the Internet Identity Workshop(IIW), a semiannual 'un-conference' where the sessions are not determined ahead of time. It is attended by a large set of people who work on Internet security and identity standards such as OAuth, OpenID, SAML, InfoCards, etc. A major theme within the identity community this year has been about improving the user experience and growing the adoption of these technologies. The OpenID community is making great progress on user experience, with Yahoo, AOL, and Google quickly improving the support they provide (read summary from Joseph Smarr of Plaxo). Similarly, the InfoCard community has been working on simplifying the user experience of InfoCard technology, including the updated CardSpace selector from Microsoft.
Another hot topic at IIW centered around how to improve the user experience when testing alternatives and enhancements to passwords to make them less susceptible to phishing attacks. Many websites and enterprises have tried these password enhancements/alternatives, but they found that people complained that they were hard to use, or that they weren't portable enough for people who use multiple computers, including web cafes and smart phones. We have published an article summarizing some of the community's current ideas for how to deploy these new authentication mechanisms using a multi-layered approach that minimizes additional work required by users. We have also pulled together a set of videos showing how a number of these different approaches work with both web-based and desktop applications. We hope this information will be helpful to other websites and enterprises who are concerned about phishing.
[Also posted on the Google Online Security Blog.]2013, By: Seo Master
One of the major conferences on Internet identity standards is the Internet Identity Workshop(IIW), a semiannual 'un-conference' where the sessions are not determined ahead of time. It is attended by a large set of people who work on Internet security and identity standards such as OAuth, OpenID, SAML, InfoCards, etc. A major theme within the identity community this year has been about improving the user experience and growing the adoption of these technologies. The OpenID community is making great progress on user experience, with Yahoo, AOL, and Google quickly improving the support they provide (read summary from Joseph Smarr of Plaxo). Similarly, the InfoCard community has been working on simplifying the user experience of InfoCard technology, including the updated CardSpace selector from Microsoft.
Another hot topic at IIW centered around how to improve the user experience when testing alternatives and enhancements to passwords to make them less susceptible to phishing attacks. Many websites and enterprises have tried these password enhancements/alternatives, but they found that people complained that they were hard to use, or that they weren't portable enough for people who use multiple computers, including web cafes and smart phones. We have published an article summarizing some of the community's current ideas for how to deploy these new authentication mechanisms using a multi-layered approach that minimizes additional work required by users. We have also pulled together a set of videos showing how a number of these different approaches work with both web-based and desktop applications. We hope this information will be helpful to other websites and enterprises who are concerned about phishing.
[Also posted on the Google Online Security Blog.]2013, By: Seo Master
seo Google’s sample OpenID relying party site 2013
Seo Master present to you:
More and more websites are enhancing their login systems to include buttons for identity providers such as Google, Yahoo, Facebook, Twitter, Microsoft, etc. Users generally prefer this approach because it makes it easier for them to sign up for a new site that they visit. However if a user already has an account at a website, and they are used to logging in with their email and password, then it is hard to get them to switch to using an identity provider.
Google has recently released a sample site that shows how a website can migrate users away from password based logins, and instead have them leverage an identity provider. This sample site incorporates many of the ideas of the Internet Identity community, as well as feedback from numerous websites who have been on the cutting edge of applying these techniques. The following video provides highlights of some elements of the user experience.
The sample site is at openidsamplestore.com, but we suggest first reading this FAQ which describes the site and has links to additional videos of some of the features. We hope website developers will use these techniques to reduce the need for passwords on their site.
2013, By: Seo Masterseo Hybrid Onboarding 2013
Seo Master present to you: Do you operate a website and wish you could increase the percentage of users who finish the registration process? As discussed on Google's main blog, Google has been working with Plaxo and Facebook to improve the registration success rate for Gmail users. We now see success rates as high as 90%, compared to the 50-60% rate that most websites see with traditional registration mechanisms. This result was achieved using a combination of our OpenID, OAuth and Portable Contacts APIs. While those APIs have been available for over a year, we have added a number of refinements based on our experience with Plaxo and Facebook. Our documentation now has information on those new features, including:
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:
2013, By: Seo Master
- 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.
2013, By: Seo Master
seo Moving another step closer to single-sign on 2013
Seo Master present to you: By Eric Sachs, Google Security Team
Yesterday we announced one step we took to help increase adoption of single-sign on across websites on the Internet. For more details, you can watch today's episode of thesocialweb.tv which covers the launch. While we announced that we would initially provide limited access to our OpenID IDP to make sure it was working properly, we were delighted to see that the number of sites that registered to receive access was significantly more than we had expected. So instead of having our engineers spend time manually maintaining that list of registered sites, we are now taking another step further and removing that restriction so any site can use the API.
That registration requirement also led to some confusion because users wanted to be able to use existing websites that accept OpenID 2.0 compliant logins by simply entering "gmail.com" (or in some cases their full E-mail address) into the login boxes on those websites. Normally what would happen after a user typed gmail.com is that the relying party website would look for a special type of file (XRDS) on the gmail.com servers that would check if Gmail run an OpenID identity provider. For yesterday's launch, we specifically chose not to publish that special XRDS file on gmail.com because if we had published the file, users would have received an error at Google if the website they were trying to log into had not registered with us. Now that we have removed the registration requirement, we will work on pushing that XRDS file as quickly as possible. Once the XRDS file is live, end-users should be able to use the service by typing gmail.com in the OpenID field of any login box that supports OpenID 2.0, similar to how Yahoo users can type yahoo.com or their Yahoo E-mail address. (In the meantime, if you feel really geeky, you can type "https://www.google.com/accounts/o8/id" into an OpenID 2.0 compliant login box and see the directed identity workflow in action.)
However, as we we noted in the Designing a Login User Interface section of our documentation, we do not place any requirements on the design of a federated login box on a relying party website. There are many approaches used by websites today, and the community is still experimenting with new approaches.
One other question that a lot of people asked yesterday is when a large provider like Google will become a relying party. There is one big problem that stands in the way of doing that, but fortunately it is more of a technology problem than a usability issue. That problem is that rich-client apps (desktop apps and mobile apps) are hard-coded to ask a user for their username and password. As an example, all Google rich-client apps would break if we supported federated login for our consumer users, and in fact they do break for the large number of our enterprise E-mail outsourcing customers who run their own identity provider, and for which Google is a relying party today. This problem with rich-client apps also affects other sites like Plaxo who are already relying parties.
Google is committed to working on this problem. If community members also want to help in this area, please take a look at our research on combining rich-client apps with federated login which was discussed at the recent UX summit and discussed further in a blog post here. A key thing to notice is that this research is about another open source technology called OAuth, and is agnostic to the particular federated login technology used, i.e. SAML or OpenID. It is also agnostic to the type of strong authentication method (if any) that is used to authenticate the user.
To further increase the adoption of federated login, we need standard open-source components on as many platforms as possible to enable those rich-client apps to support OAuth. That includes a lot more platforms then just Windows and Mac. The harder part is mobile devices (Blackberry, Symbian, Windows Mobile, iPhone, and yes even Android), and other Internet connected devices like Tivos, Apple TVs, Playstations, etc. that have rich-client apps that ask users for their passwords to access services like Youtube, Google photos, etc. If the community works together to build these components, they will be useful not only to Google, but also to any other relying parties that have rich-client apps or that expose APIs, and it will also help enterprise SaaS vendors like Salesforce.
If you want to help further these efforts, join the OpenID and OAuth mailing lists and tell people which platform you are targeting in case others want to help. For example, Mike Malone from Pownce did some work a few months ago to use OAuth on an iPhone and described how he got it working. And just yesterday another member of the open source community, Sean Sullivan, built a working OAuth enabled rich-client app for Android and posted the open source code.2013, By: Seo Master
Yesterday we announced one step we took to help increase adoption of single-sign on across websites on the Internet. For more details, you can watch today's episode of thesocialweb.tv which covers the launch. While we announced that we would initially provide limited access to our OpenID IDP to make sure it was working properly, we were delighted to see that the number of sites that registered to receive access was significantly more than we had expected. So instead of having our engineers spend time manually maintaining that list of registered sites, we are now taking another step further and removing that restriction so any site can use the API.
That registration requirement also led to some confusion because users wanted to be able to use existing websites that accept OpenID 2.0 compliant logins by simply entering "gmail.com" (or in some cases their full E-mail address) into the login boxes on those websites. Normally what would happen after a user typed gmail.com is that the relying party website would look for a special type of file (XRDS) on the gmail.com servers that would check if Gmail run an OpenID identity provider. For yesterday's launch, we specifically chose not to publish that special XRDS file on gmail.com because if we had published the file, users would have received an error at Google if the website they were trying to log into had not registered with us. Now that we have removed the registration requirement, we will work on pushing that XRDS file as quickly as possible. Once the XRDS file is live, end-users should be able to use the service by typing gmail.com in the OpenID field of any login box that supports OpenID 2.0, similar to how Yahoo users can type yahoo.com or their Yahoo E-mail address. (In the meantime, if you feel really geeky, you can type "https://www.google.com/accounts/o8/id" into an OpenID 2.0 compliant login box and see the directed identity workflow in action.)
However, as we we noted in the Designing a Login User Interface section of our documentation, we do not place any requirements on the design of a federated login box on a relying party website. There are many approaches used by websites today, and the community is still experimenting with new approaches.
One other question that a lot of people asked yesterday is when a large provider like Google will become a relying party. There is one big problem that stands in the way of doing that, but fortunately it is more of a technology problem than a usability issue. That problem is that rich-client apps (desktop apps and mobile apps) are hard-coded to ask a user for their username and password. As an example, all Google rich-client apps would break if we supported federated login for our consumer users, and in fact they do break for the large number of our enterprise E-mail outsourcing customers who run their own identity provider, and for which Google is a relying party today. This problem with rich-client apps also affects other sites like Plaxo who are already relying parties.
Google is committed to working on this problem. If community members also want to help in this area, please take a look at our research on combining rich-client apps with federated login which was discussed at the recent UX summit and discussed further in a blog post here. A key thing to notice is that this research is about another open source technology called OAuth, and is agnostic to the particular federated login technology used, i.e. SAML or OpenID. It is also agnostic to the type of strong authentication method (if any) that is used to authenticate the user.
To further increase the adoption of federated login, we need standard open-source components on as many platforms as possible to enable those rich-client apps to support OAuth. That includes a lot more platforms then just Windows and Mac. The harder part is mobile devices (Blackberry, Symbian, Windows Mobile, iPhone, and yes even Android), and other Internet connected devices like Tivos, Apple TVs, Playstations, etc. that have rich-client apps that ask users for their passwords to access services like Youtube, Google photos, etc. If the community works together to build these components, they will be useful not only to Google, but also to any other relying parties that have rich-client apps or that expose APIs, and it will also help enterprise SaaS vendors like Salesforce.
If you want to help further these efforts, join the OpenID and OAuth mailing lists and tell people which platform you are targeting in case others want to help. For example, Mike Malone from Pownce did some work a few months ago to use OAuth on an iPhone and described how he got it working. And just yesterday another member of the open source community, Sean Sullivan, built a working OAuth enabled rich-client app for Android and posted the open source code.2013, By: Seo Master
seo Google moves towards single sign-on with OpenID 2013
Seo Master present to you: By Eric Sachs, Google Security Team
Currently users are required to create individual passwords for many websites they visit, but users would prefer to avoid this step so they could visits websites more easily. Similarly, many websites on the Internet have asked for a way to enable users to log into their sites without forcing them to create another password. If users could log into sites without needing another password, it would allow websites to provide a more personalized experience to their users.
In September we announced some research that we shared as part of an effort by the OpenID community to evaluate the user experience of federated login. Other companies like Yahoo have also published their user research. Starting today, we are providing limited access to an API for an OpenID identity provider that is based on the user experience research of the OpenID community. Websites can now allow Google Account users to login to their website by using the OpenID protocol. We hope the continued evolution of both the technical features of OpenID, as well as the improvements in user experience. will lead to a solution that can be widely deployed for federated login. One of the companies using this new service is www.zoho.com. Raju Vegesna at ZoHo says that "We now offer all our users the ability to login to ZoHo using their Google Account to avoid the need to create yet another login and password."
The initial version of the API will use the OpenID 2.0 protocol to enable websites to validate the identity of a Google Account user, including the optional ability to request the user's e-mail address. Below is an example of the flow that a user might see if he or she starts at a website that uses this new feature:
The website could use a modified login box that looks like the one below. If the user enters a Gmail address and indicates that he or she does not have a password for this site, then the site can redirect him or her to Google.
The user would then be taken to the Google website and asked to confirm whether he or she wants to sign in to KidMallPics.
Finally, the user would be redirected back to KidMallPics, where he or she would be immediately signed in.
More information about this new API can be found on the Open ID page in Google Code. To request access to the limited trial, please visit our Google Federated Login discussion group and register using the online registration form.
Google is also working with the open source community on ways to combine the OAuth and OpenID protocol in the future. That way a website can not only request the user's identity and e-mail address, but can also request access to information available via OAuth-enabled APIs such as Google Data APIs as well as standard data formats such as Portable Contacts and OpenSocial REST APIs. In the future, this should allow a website to immediately provide a much more streamlined, personalized and socially relevant experience for users when they log in to trusted websites.2013, By: Seo Master
Currently users are required to create individual passwords for many websites they visit, but users would prefer to avoid this step so they could visits websites more easily. Similarly, many websites on the Internet have asked for a way to enable users to log into their sites without forcing them to create another password. If users could log into sites without needing another password, it would allow websites to provide a more personalized experience to their users.
In September we announced some research that we shared as part of an effort by the OpenID community to evaluate the user experience of federated login. Other companies like Yahoo have also published their user research. Starting today, we are providing limited access to an API for an OpenID identity provider that is based on the user experience research of the OpenID community. Websites can now allow Google Account users to login to their website by using the OpenID protocol. We hope the continued evolution of both the technical features of OpenID, as well as the improvements in user experience. will lead to a solution that can be widely deployed for federated login. One of the companies using this new service is www.zoho.com. Raju Vegesna at ZoHo says that "We now offer all our users the ability to login to ZoHo using their Google Account to avoid the need to create yet another login and password."
The initial version of the API will use the OpenID 2.0 protocol to enable websites to validate the identity of a Google Account user, including the optional ability to request the user's e-mail address. Below is an example of the flow that a user might see if he or she starts at a website that uses this new feature:
The website could use a modified login box that looks like the one below. If the user enters a Gmail address and indicates that he or she does not have a password for this site, then the site can redirect him or her to Google.
The user would then be taken to the Google website and asked to confirm whether he or she wants to sign in to KidMallPics.
Finally, the user would be redirected back to KidMallPics, where he or she would be immediately signed in.
More information about this new API can be found on the Open ID page in Google Code. To request access to the limited trial, please visit our Google Federated Login discussion group and register using the online registration form.
Google is also working with the open source community on ways to combine the OAuth and OpenID protocol in the future. That way a website can not only request the user's identity and e-mail address, but can also request access to information available via OAuth-enabled APIs such as Google Data APIs as well as standard data formats such as Portable Contacts and OpenSocial REST APIs. In the future, this should allow a website to immediately provide a much more streamlined, personalized and socially relevant experience for users when they log in to trusted websites.2013, By: Seo Master
seo Simpler Access to Flickr for Google Users with OpenID 2013
Seo Master present to you: OpenID momentum continues to grow. Yahoo! announced that Google users can now sign up for a new account on Flickr’s photo-sharing service with their Google Account information, eliminating the need to create a new username and password. Flickr joins other websites such as Plaxo and Facebook that also support this simpler registration process for Google users.
Google and Yahoo! are two of the many companies who have been involved with the OpenID community’s efforts to improve the process for how users log in and sign up for online services. For example, last month Google announced its use of OpenID to make it simpler for Yahoo! users to sign up for Google services.
While Google doesn’t yet support the use of OpenID for replacing passwords on its own sites, we’re involved in the OpenID community’s efforts to research how to best implement that type of support. Yahoo!’s announcement today is another step in defining those best practices. We look forward to discussing this new feature at next week’s Internet Identity Workshop where the identity community gathers to discuss how to further accelerate the adoption of standards like OpenID.
2013, By: Seo Master
Google and Yahoo! are two of the many companies who have been involved with the OpenID community’s efforts to improve the process for how users log in and sign up for online services. For example, last month Google announced its use of OpenID to make it simpler for Yahoo! users to sign up for Google services.
While Google doesn’t yet support the use of OpenID for replacing passwords on its own sites, we’re involved in the OpenID community’s efforts to research how to best implement that type of support. Yahoo!’s announcement today is another step in defining those best practices. We look forward to discussing this new feature at next week’s Internet Identity Workshop where the identity community gathers to discuss how to further accelerate the adoption of standards like OpenID.
2013, By: Seo Master
seo Usability Research on Federated Login 2013
Seo Master present to you: By Eric Sachs, Product Manager, Google Security
Federated login has been a goal of the Internet community for a long time, but its usage is still quite low, especially in the consumer space. This has led to the constant need for users to create yet another account to log in to a new website, and most consumers use the same password across websites even though they realize this is a poor security practice. In the enterprise space, many software-as-a-service vendors such as Salesforce.com and Google Apps for Your Domain do support federated login, but even those vendors encounter usability problems.
On September 12 the OpenID Foundation held a meeting to gather feedback on how to evolve the best practices for using OpenID so that it might be used by websites in a larger number of market segments. The meeting included representatives from many mainstream websites including The New York Times, BBC, AARP, Time Inc., and NPR. Google has been researching federated login techniques, and at the meeting we showed how a traditional login box might evolve (see below) to a new style of login box that better supports federated login.
We also shared a summary of our usability research that explains how this helps a website add support for federated login for some users without hurting usability for the rest of the website's user base. We hope that industry groups, such as this committee in the OpenID Foundation, will continue to share ideas and experiences so we can develop a model for federated login that can be broadly deployed by websites and broadly used by consumers. If your company has experience or research that you can share, we hope you will get involved with the OpenID community and join the further discussions on this topic.2013, By: Seo Master
Federated login has been a goal of the Internet community for a long time, but its usage is still quite low, especially in the consumer space. This has led to the constant need for users to create yet another account to log in to a new website, and most consumers use the same password across websites even though they realize this is a poor security practice. In the enterprise space, many software-as-a-service vendors such as Salesforce.com and Google Apps for Your Domain do support federated login, but even those vendors encounter usability problems.
On September 12 the OpenID Foundation held a meeting to gather feedback on how to evolve the best practices for using OpenID so that it might be used by websites in a larger number of market segments. The meeting included representatives from many mainstream websites including The New York Times, BBC, AARP, Time Inc., and NPR. Google has been researching federated login techniques, and at the meeting we showed how a traditional login box might evolve (see below) to a new style of login box that better supports federated login.
We also shared a summary of our usability research that explains how this helps a website add support for federated login for some users without hurting usability for the rest of the website's user base. We hope that industry groups, such as this committee in the OpenID Foundation, will continue to share ideas and experiences so we can develop a model for federated login that can be broadly deployed by websites and broadly used by consumers. If your company has experience or research that you can share, we hope you will get involved with the OpenID community and join the further discussions on this topic.2013, By: Seo Master
seo Sign up with Google using OpenID 2013
Seo Master present to you:
Some websites use the OpenID standard so that users don’t even need to type a password to sign in. While Google does not yet support the usage of OpenID for replacing passwords on its own sites, we are involved in the OpenID community’s efforts to research how to best implement that type of support.
As a next step in those community efforts, we announced today the use of OpenID for the Google signup process.
Currently, Google only offers this feature for Yahoo! users. However, as it is based on an Internet standard, we plan to use it in the future with other email providers that add support for this usage of OpenID and related standards like OAuth, such as in the Microsoft Live identity APIs.
Other websites that need to verify a user’s email address can also implement this technique using Yahoo!’s OpenID API. In addition, it can be used to verify the addresses of Gmail and Google Apps users because those email systems expose the necessary APIs for OpenID. For example, Plaxo is one of the many websites that takes advantage of this feature of Gmail and Yahoo! Mail.
2013, By: Seo Masterseo Google Apps + OpenID = identity hub for SaaS 2013
Seo Master present to you: We're happy to announce that the Google OpenID Federated Login API has been extended to Google Apps accounts used by businesses, schools, and other organizations. Individuals in these organizations can now sign in to third party websites using their Google Apps account, without sharing their credentials with third parties.
In addition, Google Apps can now become an identity hub for multiple SaaS providers, simplifying identity management for organizations. For example, when integrated with partner solutions such as PingConnect from Ping Identity, the Google Open ID Federated Login API enables a single Google Apps login to help provide secure access to services like Salesforce.com, SuccessFactors, and WebEX — as well as B2B partners, internal applications, and of course consumer web sites. See Ping Identity's post to learn more about their implementation and view the demo.
In the Manymoon Login page, the user chooses to log in using a Google Apps account
The user is redirected to the Google Apps domain to approve sharing information with Manymoon.
If you prefer an out-of-the-box solution, we have been working with JanRain, a provider of OpenID solutions that already supports the new API as part of their RPX product.
You can find more details in our API and Discovery documentation, or join the discussions in the Google Federated Login API Group, where you can ask any question and get answers from other Identity Providers, Relying Parties and Google engineers.
The OpenID Federated Login Service is available for all Google Apps editions. However, it is disabled by default for the Premier and Education editions, and it requires the domain administrator to manually enable it from the Control Panel. We've enabled the service for our employees here at Google, and domain administrators — you can also enable it for your domain.
2013, By: Seo Master
In addition, Google Apps can now become an identity hub for multiple SaaS providers, simplifying identity management for organizations. For example, when integrated with partner solutions such as PingConnect from Ping Identity, the Google Open ID Federated Login API enables a single Google Apps login to help provide secure access to services like Salesforce.com, SuccessFactors, and WebEX — as well as B2B partners, internal applications, and of course consumer web sites. See Ping Identity's post to learn more about their implementation and view the demo.
In the Manymoon Login page, the user chooses to log in using a Google Apps account
The user types in his Google Apps email address. The user never gives away his Google Apps Account password to Manymoon.
The user is redirected to the Google Apps domain to approve sharing information with Manymoon.
Once approved, the user is redirected to Manymoon and is signed in and ready to work with selected accounts.
You can find more details in our API and Discovery documentation, or join the discussions in the Google Federated Login API Group, where you can ask any question and get answers from other Identity Providers, Relying Parties and Google engineers.
The OpenID Federated Login Service is available for all Google Apps editions. However, it is disabled by default for the Premier and Education editions, and it requires the domain administrator to manually enable it from the Control Panel. We've enabled the service for our employees here at Google, and domain administrators — you can also enable it for your domain.
2013, By: Seo Master
seo MySpace Open Platform: Connect MySpace users to your site and to your apps 2013
Seo Master present to you: This post is part of the Who's @ Google I/O, a series of blog posts that give a closer look at developers who'll be speaking or demoing at Google I/O. Today's post is a guest post written by Scott Seely, Architect for the MySpace Open Platform.
MySpace will be talking about two big things at Google I/O this year: MySpaceID and MySpace Apps.
MySpaceID delivers social functionality and experiences by linking MySpace accounts with your site. These services allow users to quickly register using their MySpace credentials as well as post status messages, publish activities into MySpace, discover friends, and view MySpace activity and profile data on your site! The users’ friends see all these updates, which drive traffic to your site and attract new users to register. By leveraging MySpace’s social graph, you add virally to the buzz about your site and increase the number of visitors to it.
For a broad overview of MySpaceID, please watch this video:
We provide SDKs for MySpaceID. You can use the SDKs or directly use our REST endpoints. We have SDKs available for a variety of languages: PHP, Python, Ruby, .NET, Java, and JavaScript. This brings the benefits of MySpaceID to a wide range of developers. The JavaScript SDK runs on the client, all other versions run on your servers. These options allow you to achieve smooth workflows and reduce implementation costs by working with the skills you use as a developer.
MySpaceID supports both OAuth and the OpenID-Auth hybrid—you choose the mechanism that makes the most sense for your scenario. Both options are exposed in our SDKs. Once a user logs in and allows your site to access their data, you have access to a wealth of their MySpace data. The MySpace endpoints support Portable Contacts and OpenSocial 0.9 REST, giving you access to plenty of information.
MySpace Apps provides developers with a canvas to create engaging social applications that are deeply integrated into MySpace. The applications are built using the OpenSocial specification, which we are evolving with partners like Google, and Yahoo!. With OpenSocial 0.9, you will see advances in markup, allowing you to remove much of your JavaScript and instead use OpenSocial Markup Language, OSML, to declare which friends you want loaded. This work all happens on MySpace’s servers, reducing calls for data and greatly improving the application experience. When you do need to contact your own servers, you can send Ajax calls through our proxies to your servers. These calls are all signed by the MySpace infrastructure so that you know the request came from a trusted source. The MySpaceID SDK allows your server to access and set MySpace user data in this scenario. So long as the user has installed your application, your servers can access their data.
These are some of the ways that MySpaceID enables you to leverage MySpace API’s off-site and let users into your site with their social media identity and data. Earlier this year, MySpace was the first social network to allow syndication of its users’ activity streams. We hope you are as excited as we are to be part of this fundamental shift in the portability of user identity and data on the Internet.
MySpace Apps and MySpaceID are a lot more than what we’ve talked about here. We invite you to find out more by attending:
2013, By: Seo Master
MySpace will be talking about two big things at Google I/O this year: MySpaceID and MySpace Apps.
MySpaceID delivers social functionality and experiences by linking MySpace accounts with your site. These services allow users to quickly register using their MySpace credentials as well as post status messages, publish activities into MySpace, discover friends, and view MySpace activity and profile data on your site! The users’ friends see all these updates, which drive traffic to your site and attract new users to register. By leveraging MySpace’s social graph, you add virally to the buzz about your site and increase the number of visitors to it.
For a broad overview of MySpaceID, please watch this video:
We provide SDKs for MySpaceID. You can use the SDKs or directly use our REST endpoints. We have SDKs available for a variety of languages: PHP, Python, Ruby, .NET, Java, and JavaScript. This brings the benefits of MySpaceID to a wide range of developers. The JavaScript SDK runs on the client, all other versions run on your servers. These options allow you to achieve smooth workflows and reduce implementation costs by working with the skills you use as a developer.
MySpaceID supports both OAuth and the OpenID-Auth hybrid—you choose the mechanism that makes the most sense for your scenario. Both options are exposed in our SDKs. Once a user logs in and allows your site to access their data, you have access to a wealth of their MySpace data. The MySpace endpoints support Portable Contacts and OpenSocial 0.9 REST, giving you access to plenty of information.
MySpace Apps provides developers with a canvas to create engaging social applications that are deeply integrated into MySpace. The applications are built using the OpenSocial specification, which we are evolving with partners like Google, and Yahoo!. With OpenSocial 0.9, you will see advances in markup, allowing you to remove much of your JavaScript and instead use OpenSocial Markup Language, OSML, to declare which friends you want loaded. This work all happens on MySpace’s servers, reducing calls for data and greatly improving the application experience. When you do need to contact your own servers, you can send Ajax calls through our proxies to your servers. These calls are all signed by the MySpace infrastructure so that you know the request came from a trusted source. The MySpaceID SDK allows your server to access and set MySpace user data in this scenario. So long as the user has installed your application, your servers can access their data.
These are some of the ways that MySpaceID enables you to leverage MySpace API’s off-site and let users into your site with their social media identity and data. Earlier this year, MySpace was the first social network to allow syndication of its users’ activity streams. We hope you are as excited as we are to be part of this fundamental shift in the portability of user identity and data on the Internet.
MySpace Apps and MySpaceID are a lot more than what we’ve talked about here. We invite you to find out more by attending:
- “Building a Business with Social Apps” – Gerard Capiel, VP of Product for the MySpace Open Platform, will share his experiences on monetization of apps.
- Developer Sandbox – Come by and see actual apps in action, try building an app on the spot, and talk to our developers.
- Fireside Chat - Ask those hard questions, discuss approaches to problems, and think about the future with MySpace developers and the OpenSocial engineering team
2013, By: Seo Master
seo Google OpenID API - taking the next steps 2013
Seo Master present to you: Six months ago, we announced our first step in supporting single sign-on using OpenID. Well, we wanted to share with you what we have been working on since. As a strong supporter of open standards such as OpenID, Google's top priority in this area has been to join the OpenID community in its efforts to increase the adoption of the protocol by both Relying Party websites and end users. In order to achieve that goal, we have been experimenting with new ways to improve OpenID usability and extend its functionality.
Our first enhancement, announced in January 2009, was to introduce the "Hybrid Protocol" API - combining OpenID's federated login with the OAuth access authorization. The Hybrid Protocol allows websites to ask Google to authenticate a user through their Google Account, while at the same time requesting access to information available via OAuth - enabled APIs such as the Google Data APIs. By combining the two protocols together, the Relying Party provides a better overall user experience and significantly reduces latency by cutting down the number of browser redirects and roundtrips. Plaxo, one of the websites using the Hybrid Protocol, published a presentation pointing out an amazing 92% success rate while experimenting with the API.
We are happy to announce today two new enhancements to our API - introducing a new popup style UI for our user facing approval page, and extending our Attribute Exchange support to include first and last name, country and preferred language.
The new popup style UI, which implements the OpenID User Interface Extension Specification, is designed to streamline the federated login experience for users. Specifically, it's designed to ensure that the context of the Relying Party website is always available and visible, even in the extreme case where a confused user closes the Google approval window. JanRain, a provider of OpenID solutions, is an early adopter of the new API, and already offers it as part of their RPX product. As demonstrated by UserVoice using JanRain's RPX, the initial step on the sign-in page of the Relying Party website is identical to that of the "full page" version, and does not require any changes in the Relying Party UI.
Once the user selects to sign in using his or her Google Account, the Google approval page is displayed. However, it does not replace the Relying Party's page in the main browser window. Instead it is displayed as a popup window on top of it. We have updated our Open Source project to include a complete Relying Party example, providing code for both the back-end (in Java) and front-end (javascript) components.
Once the user approves the request, the popup page closes, and the user is signed in to the Relying Party website.
Note that the popup style UI does not replace Google's existing full-page version, nor does it change the current behavior of our existing Relying Parties. It is up to the Relying Party to decide which of the two available formats they prefer, and modify their OpenID request accordingly as defined in the Google API Documentation.
As you can see in the screenshots provided, the user is not just signing in using her Google Account, but is also sharing specific information from her Google Account with the Relying Party website. This information may be either static fields (using Attribute Extension) such as the user's email, first and last name, preferred language and country, or allowing access to any available Google Data API such as the user's Contacts List, Web Albums, or Calendar (using OAuth). Google strongly believes that the data our users trust us with belongs to them and should always be available for them to use. By providing users with more secure means to share their data, they can benefit from a much more streamlined, personalized and socially relevant experience when they log in to trusted websites. At the same time, Relying Parties can significantly simplify their account creation and sign-in flows, resulting in happier users and higher successful registration rates.
If you want to know what's coming next and impact what the future advancements are, you are welcome to join the OpenID and OAuth mailing lists.
2013, By: Seo Master
Our first enhancement, announced in January 2009, was to introduce the "Hybrid Protocol" API - combining OpenID's federated login with the OAuth access authorization. The Hybrid Protocol allows websites to ask Google to authenticate a user through their Google Account, while at the same time requesting access to information available via OAuth - enabled APIs such as the Google Data APIs. By combining the two protocols together, the Relying Party provides a better overall user experience and significantly reduces latency by cutting down the number of browser redirects and roundtrips. Plaxo, one of the websites using the Hybrid Protocol, published a presentation pointing out an amazing 92% success rate while experimenting with the API.
We are happy to announce today two new enhancements to our API - introducing a new popup style UI for our user facing approval page, and extending our Attribute Exchange support to include first and last name, country and preferred language.
The new popup style UI, which implements the OpenID User Interface Extension Specification, is designed to streamline the federated login experience for users. Specifically, it's designed to ensure that the context of the Relying Party website is always available and visible, even in the extreme case where a confused user closes the Google approval window. JanRain, a provider of OpenID solutions, is an early adopter of the new API, and already offers it as part of their RPX product. As demonstrated by UserVoice using JanRain's RPX, the initial step on the sign-in page of the Relying Party website is identical to that of the "full page" version, and does not require any changes in the Relying Party UI.
Once the user selects to sign in using his or her Google Account, the Google approval page is displayed. However, it does not replace the Relying Party's page in the main browser window. Instead it is displayed as a popup window on top of it. We have updated our Open Source project to include a complete Relying Party example, providing code for both the back-end (in Java) and front-end (javascript) components.
Once the user approves the request, the popup page closes, and the user is signed in to the Relying Party website.
Note that the popup style UI does not replace Google's existing full-page version, nor does it change the current behavior of our existing Relying Parties. It is up to the Relying Party to decide which of the two available formats they prefer, and modify their OpenID request accordingly as defined in the Google API Documentation.
As you can see in the screenshots provided, the user is not just signing in using her Google Account, but is also sharing specific information from her Google Account with the Relying Party website. This information may be either static fields (using Attribute Extension) such as the user's email, first and last name, preferred language and country, or allowing access to any available Google Data API such as the user's Contacts List, Web Albums, or Calendar (using OAuth). Google strongly believes that the data our users trust us with belongs to them and should always be available for them to use. By providing users with more secure means to share their data, they can benefit from a much more streamlined, personalized and socially relevant experience when they log in to trusted websites. At the same time, Relying Parties can significantly simplify their account creation and sign-in flows, resulting in happier users and higher successful registration rates.
If you want to know what's coming next and impact what the future advancements are, you are welcome to join the OpenID and OAuth mailing lists.
2013, By: Seo Master
seo Join us in London for an OpenID Workshop 2013
Seo Master present to you: 
By Eric Sachs, Senior Product Manager, Google Identity Team
UPDATE (March 7): Following our post two weeks ago, this event sold out almost immediately. To accommodate more people, the event has been moved to a larger room at Microsoft’s offices in London. For more details on agenda, speakers, location, and registration, please visit the event site.
The OpenID Foundation is hosting an OpenID workshop on March 28th that will be located at Google’s London office (UPDATE: moved to Microsoft’s London office). Google uses OpenID in a number of its services, and is a corporate member of the OpenID Foundation. The OpenID Foundation runs a series of workshops like this one for business decision makers, as well as running other OpenID summits that are more technical.
The event is for the owners of consumer websites and enterprise SaaS services to discuss how to improve login systems by using techniques such as OAuth, OpenID and an Account Chooser.
Please join us in London on Wednesday, March 28th, 2012 from 10:00 until 17:30 GMT. For more details on agenda, speakers, location, and registration, visit the event site.
In addition to the OpenID workshop, there is a similar event the previous day on identity security best practices, hosted by Ping Identity and sponsored by Google.
Eric Sachs has been a product manager at Google since 2003. He is now involved with industry efforts to increase adoption of Internet Identity standards including OAuth and OpenID.
Posted by Scott Knaster, Editor
2013, By: Seo Master
By Eric Sachs, Senior Product Manager, Google Identity Team
UPDATE (March 7): Following our post two weeks ago, this event sold out almost immediately. To accommodate more people, the event has been moved to a larger room at Microsoft’s offices in London. For more details on agenda, speakers, location, and registration, please visit the event site.
The OpenID Foundation is hosting an OpenID workshop on March 28th that will be located at Google’s London office (UPDATE: moved to Microsoft’s London office). Google uses OpenID in a number of its services, and is a corporate member of the OpenID Foundation. The OpenID Foundation runs a series of workshops like this one for business decision makers, as well as running other OpenID summits that are more technical.
The event is for the owners of consumer websites and enterprise SaaS services to discuss how to improve login systems by using techniques such as OAuth, OpenID and an Account Chooser.
Please join us in London on Wednesday, March 28th, 2012 from 10:00 until 17:30 GMT. For more details on agenda, speakers, location, and registration, visit the event site.
In addition to the OpenID workshop, there is a similar event the previous day on identity security best practices, hosted by Ping Identity and sponsored by Google.
Eric Sachs has been a product manager at Google since 2003. He is now involved with industry efforts to increase adoption of Internet Identity standards including OAuth and OpenID.
Posted by Scott Knaster, Editor
2013, By: Seo Master