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 Upcoming changes to OAuth 2.0 endpoint 2013
Seo Master present to you: 
By Justin Smith, Senior Product Manager
UPDATE 11/14: After considering the feedback and timing, we have decided to delay the launch of the changes described in this post. The new date for these changes is December 7th, 2011. Once again, we expect these changes to have minimal impact. If you have any questions or comments, please post on the OAuth 2.0 Group. We will be actively monitoring that group and will work to respond quickly.
Original post:
In the coming weeks we will be making three changes to the experimental OAuth 2.0 endpoint. We expect the impact to be minimal, and we’re emailing developers who are most likely to be affected.
We will be releasing these changes on December 7, 2011. This post describes the changes, their impact, and how they can be mitigated.
Change #1: Error responses for client-side web applications
The first change relates to the way errors are returned in OAuth 2.0 client-side web applications. It does not impact server-side, native, or device flows.
The current behavior of the OAuth 2.0 endpoint in certain error conditions is to return the error to the application as a query string parameter, for example:
The OAuth 2.0 specification indicates that the error should be returned in the fragment of the response. We are updating our OAuth 2.0 implementation to support the most recent draft of the specification. As a result, we will be changing the way we return errors to applications in the client-side flow.
As an example, today an error returns to your application as
There is no mitigation for this change, so your application will have to handle these types of errors in client-side script.
Change #2: Offline access as a separate parameter
The second change impacts the OAuth 2.0 server-side flow only. It does not impact client-side, native, or device flows. For context, this flow consists of the following steps:
The client-side flow, in contrast, requires the user to be present when obtaining an access token. This type of access is called online.
With this change, we will be exposing online and offline access as a separate parameter that’s available only in the server-side flow.
When your application requests offline access, the consent page shown to a user will reflect that your application requests offline access and your application will receive an access and a refresh token. Once your application has a refresh token, it may obtain a new access token at any time.
When your application requests online access, your application will only receive an access token. No refresh token will be returned. This means that a user must be present in order for your application to obtain a new access token.
If unspecified in the request, online is the default.
A mitigation for this change is described at the end of this post.
Change #3: Server-side auto-approval
This change also impacts the OAuth 2.0 server-side flow only.
In the current implementation of OAuth2, every time your application redirects a user to Google, that user must give explicit consent before an authorization code is given to your application. As a result, sending a user through the flow another time requires them to see the consent screen again. Most applications don’t do this, but rather use the existing server-side flow as it was intended: a one-time association (import contacts, calendar operations, etc.) where the result is a refresh token which may be used to obtain new access tokens.
The behavior is changing to the following:
The next section describes how to mitigate this change.
Mitigation of offline access (#2) and auto-approval (#3) changes
If you want to keep the existing behavior in your server-side applications, include the
For example, if the following is a target URL for obtaining an authorization code today:
Questions?
If you have any questions or comments, please post on the OAuth 2.0 Group (https://groups.google.com/forum/#!forum/OAuth 2.0-dev). We will be actively monitoring that group and will work to respond quickly.
Justin Smith is a Product Manager who works on authentication and authorization technologies at Google. He enjoys woodworking, cycling, country music, and the company of his wife (not necessarily in that order).
Posted by Scott Knaster, Editor
2013, By: Seo Master
By Justin Smith, Senior Product Manager
UPDATE 11/14: After considering the feedback and timing, we have decided to delay the launch of the changes described in this post. The new date for these changes is December 7th, 2011. Once again, we expect these changes to have minimal impact. If you have any questions or comments, please post on the OAuth 2.0 Group. We will be actively monitoring that group and will work to respond quickly.
Original post:
In the coming weeks we will be making three changes to the experimental OAuth 2.0 endpoint. We expect the impact to be minimal, and we’re emailing developers who are most likely to be affected.
We will be releasing these changes on December 7, 2011. This post describes the changes, their impact, and how they can be mitigated.
Change #1: Error responses for client-side web applications
The first change relates to the way errors are returned in OAuth 2.0 client-side web applications. It does not impact server-side, native, or device flows.
The current behavior of the OAuth 2.0 endpoint in certain error conditions is to return the error to the application as a query string parameter, for example:
https://www.example.com/back?error=access_denied.The OAuth 2.0 specification indicates that the error should be returned in the fragment of the response. We are updating our OAuth 2.0 implementation to support the most recent draft of the specification. As a result, we will be changing the way we return errors to applications in the client-side flow.
As an example, today an error returns to your application as
https://www.example.com/back?error=access_denied. After this change, it will be returned as https://www.example.com/back#error=access_denied. There is no mitigation for this change, so your application will have to handle these types of errors in client-side script.
Change #2: Offline access as a separate parameter
The second change impacts the OAuth 2.0 server-side flow only. It does not impact client-side, native, or device flows. For context, this flow consists of the following steps:
- Redirect the browser to the Google OAuth 2.0 endpoint.
- The user will be shown a consent page.
- If the user consents, parse the authorization code from the query string of the response.
- Exchange the authorization code for a short-lived access token and a long-lived refresh token.
The client-side flow, in contrast, requires the user to be present when obtaining an access token. This type of access is called online.
With this change, we will be exposing online and offline access as a separate parameter that’s available only in the server-side flow.
When your application requests offline access, the consent page shown to a user will reflect that your application requests offline access and your application will receive an access and a refresh token. Once your application has a refresh token, it may obtain a new access token at any time.
When your application requests online access, your application will only receive an access token. No refresh token will be returned. This means that a user must be present in order for your application to obtain a new access token.
If unspecified in the request, online is the default.
A mitigation for this change is described at the end of this post.
Change #3: Server-side auto-approval
This change also impacts the OAuth 2.0 server-side flow only.
In the current implementation of OAuth2, every time your application redirects a user to Google, that user must give explicit consent before an authorization code is given to your application. As a result, sending a user through the flow another time requires them to see the consent screen again. Most applications don’t do this, but rather use the existing server-side flow as it was intended: a one-time association (import contacts, calendar operations, etc.) where the result is a refresh token which may be used to obtain new access tokens.
The behavior is changing to the following:
- Users will only see the consent screen on their first time through the sequence.
- If the application requests offline access, only the first authorization code exchange results in a refresh token.
The next section describes how to mitigate this change.
Mitigation of offline access (#2) and auto-approval (#3) changes
If you want to keep the existing behavior in your server-side applications, include the
approval_prompt=force and access_type=offline parameters in an authorization code request.For example, if the following is a target URL for obtaining an authorization code today:
https://accounts.google.com/o/oauth2/auth?You can maintain the current behavior by changing the target URL to:
client_id=21302922996.apps.googleusercontent.com&
redirect_uri=https://www.example.com/back&
scope=https://www.google.com/m8/feeds/&
response_type=code
https://accounts.google.com/o/oauth2/auth?You may start including these parameters in authorization code requests today.
client_id=21302922996.apps.googleusercontent.com&
redirect_uri=https://www.example.com/back&
scope=https://www.google.com/m8/feeds/&
response_type=code&
access_type=offline&
approval_prompt=force
Questions?
If you have any questions or comments, please post on the OAuth 2.0 Group (https://groups.google.com/forum/#!forum/OAuth 2.0-dev). We will be actively monitoring that group and will work to respond quickly.
Justin Smith is a Product Manager who works on authentication and authorization technologies at Google. He enjoys woodworking, cycling, country music, and the company of his wife (not necessarily in that order).
Posted by Scott Knaster, Editor
2013, By: Seo Master
seo OAuth 2.0 Playground: open to developers 2013
Seo Master present to you: 
By Nicolas Garnier, Developer Relations Team
Cross-posted on the Google Apps Developer Blog
Exchanging the authorization code for a refresh token and an access token
Nicolas Garnier joined Google’s Developer Relations in 2008 and lives in Zurich. He is a Developer Advocate focusing on Google Apps and Web APIs. Before joining Google, Nicolas worked at Airbus and at the French Space Agency where he built web applications for scientific researchers.
Posted by Scott Knaster, Editor2013, By: Seo Master
By Nicolas Garnier, Developer Relations TeamCross-posted on the Google Apps Developer Blog
In March, we announced that all of the Google Web APIs adopted support for OAuth 2.0. It is the recommended authorization mechanism when using Google Web APIs.
Today, we are announcing the OAuth 2.0 Playground, which simplifies experimentation with the OAuth 2.0 protocol and APIs that use the protocol. Trying out some requests in the OAuth 2.0 playground can help you understand how the protocol functions and make life easier when the time comes to use OAuth in your own code.
Selecting the APIs to authorize
With the OAuth 2.0 Playground, you can walk through each step of the OAuth 2.0 flow for server-side web applications: authorizing API scopes (screen shot above), exchanging authorization tokens (screen shot below), refreshing access tokens, and sending authorized requests to API endpoints. At each step, the Playground displays the full HTTP requests and responses.
Exchanging the authorization code for a refresh token and an access tokenThe OAuth Playground can also use custom OAuth endpoints in order to test non-Google APIs that support OAuth 2.0 draft 10.
OAuth configuration screen
You can click the link button to generate a link to a specific Playground state. This allows quick access to replay specific requests at a later time.
Generating a deep link to the playground’s current state
Please feel free to try the OAuth 2.0 Playground. We are happy to receive any feedback, bugs, or questions in the OAuth Playground forum.
Nicolas Garnier joined Google’s Developer Relations in 2008 and lives in Zurich. He is a Developer Advocate focusing on Google Apps and Web APIs. Before joining Google, Nicolas worked at Airbus and at the French Space Agency where he built web applications for scientific researchers.
Posted by Scott Knaster, Editor2013, By: Seo Master
seo OAuth Enhancements 2013
Seo Master present to you: Google has recently added three important enhancements to our OAuth support:
1. The ability to use OAuth without registration
Based on consistent feedback from our developers, we added the ability to use OAuth without having to register the website ahead of time. This change is especially helpful for developers working on test servers that cannot be accessed directly from the Internet.
2. Support for software apps installed on a computer or mobile phone
Many of the larger enterprises that use the Google Apps service choose to run their own login system. They accomplish this by leveraging our support for the SAML protocol which defines a way for Google to redirect the user to the company's login system to be authenticated before accessing their mailbox at Google. However, in this situation Google normally does not have a password for the user — especially if the enterprise authenticates the user with a password and with a second factor of authentication (such as a token generator they carry on a keychain). Unfortunately, there are many installed software applications created by both Google and ISV developers that use Google's APIs, and those applications are hardcoded to ask a user for their email and password using Google's ClientLogin API. With this new OAuth feature, the software application can now launch a web browser and start a process that both logs the user in through their central SAML login system, and that also gets the user's consent to access their data hosted at Google. Because the user authentication is done in the web browser, it will work with the enterprise's existing login system. Google is encouraging any ISV that uses the ClientLogin API to add support for this new OAuth flow, enabling usage by the large enterprise customers described above. Google is also planning to enhance our Google Apps Sync for Microsoft Outlook to support this feature such that Outlook can be used with both Google Apps and an enterprise's central login system.
3. Additional controls for our Google Apps Premier and Education customers which allows administrators to give another web application access to a subset of the data Google stores for that organization
This feature for our Google Apps Premier customers enhances our existing OAuth for Google Apps domain administrators, also known as 2-legged OAuth. This feature enables domain administrators to allow specific IT apps or third party web services limited access to user accounts via a centralized permissions system under the control of the domain administrator. For example, with this new system, an administrator can use the Google Documents API to configure every user in the domain to have a Google Docs folder named "Human Resources" that is automatically populated with common employee forms. The company might also sign up with an Enterprise SaaS vendor such as Manymoon and specify that Manymoon can access the Google Calendars of all of their users, providing tighter integration with Manymoon's project scheduling features. Previously, this feature required giving the third party vendor access to all of the data that Google stored for that organization, but with this new feature, administrators can limit access to particular data sources (Calendar, Documents, etc). Refer to our documentation for more information.
2013, By: Seo Master
- The ability to use OAuth without registration
- Support for software apps installed on a computer or mobile phone
- Additional controls for our Google Apps Premier and Education customers which allows administrators to give another web application access to a subset of the data Google stores for that organization
1. The ability to use OAuth without registration
Based on consistent feedback from our developers, we added the ability to use OAuth without having to register the website ahead of time. This change is especially helpful for developers working on test servers that cannot be accessed directly from the Internet.
2. Support for software apps installed on a computer or mobile phone
Many of the larger enterprises that use the Google Apps service choose to run their own login system. They accomplish this by leveraging our support for the SAML protocol which defines a way for Google to redirect the user to the company's login system to be authenticated before accessing their mailbox at Google. However, in this situation Google normally does not have a password for the user — especially if the enterprise authenticates the user with a password and with a second factor of authentication (such as a token generator they carry on a keychain). Unfortunately, there are many installed software applications created by both Google and ISV developers that use Google's APIs, and those applications are hardcoded to ask a user for their email and password using Google's ClientLogin API. With this new OAuth feature, the software application can now launch a web browser and start a process that both logs the user in through their central SAML login system, and that also gets the user's consent to access their data hosted at Google. Because the user authentication is done in the web browser, it will work with the enterprise's existing login system. Google is encouraging any ISV that uses the ClientLogin API to add support for this new OAuth flow, enabling usage by the large enterprise customers described above. Google is also planning to enhance our Google Apps Sync for Microsoft Outlook to support this feature such that Outlook can be used with both Google Apps and an enterprise's central login system.
3. Additional controls for our Google Apps Premier and Education customers which allows administrators to give another web application access to a subset of the data Google stores for that organization
This feature for our Google Apps Premier customers enhances our existing OAuth for Google Apps domain administrators, also known as 2-legged OAuth. This feature enables domain administrators to allow specific IT apps or third party web services limited access to user accounts via a centralized permissions system under the control of the domain administrator. For example, with this new system, an administrator can use the Google Documents API to configure every user in the domain to have a Google Docs folder named "Human Resources" that is automatically populated with common employee forms. The company might also sign up with an Enterprise SaaS vendor such as Manymoon and specify that Manymoon can access the Google Calendars of all of their users, providing tighter integration with Manymoon's project scheduling features. Previously, this feature required giving the third party vendor access to all of the data that Google stored for that organization, but with this new feature, administrators can limit access to particular data sources (Calendar, Documents, etc). Refer to our documentation for more information.
2013, By: Seo Master
seo 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 New OAuth support for Google Apps APIs 2013
Seo Master present to you:
Cross-posted from the Google Enterprise Blog
Google Apps is designed to provide a secure and reliable platform for your data. Until today, Google Apps administrators had to sign requests for calls to Google Apps APIs using their username and password (this is called ClientLogin Authorization).
Yet sharing passwords across sites can pose security risks. Furthering our commitment to make the cloud more secure for our users, today we are pleased to announce support for OAuth authorization on Google Apps APIs.
There are several advantages to using OAuth instead of the username/password model:
- OAuth is more secure: OAuth tokens can be scoped and set to expire by a certain date, making them more secure than using the ClientLogin mechanism.
- OAuth is customizable: Using OAuth, you can create tokens that scripts may only use to access data of a particular scope when calling Google Apps APIs. For instance, a token set to call the Email Migration API would not be able to use your login credentials to access the Google Apps Provisioning API.
- OAuth is an open standard: OAuth is an open source standard, making it a familiar choice for developers to work with.
The Google Apps APIs that support the OAuth signing mechanism are:
- Provisioning API
- Email Migration API
- Admin Settings API
- Calendar Resource API
- Email Settings API
- Audit API
OAuth support for Google Apps APIs is another step towards making Google Apps the most secure, reliable cloud based computing environment for organizations. To learn more about OAuth support and other administrative capacities launched in Google Apps this quarter, join us for a live webinar on Wednesday, September 29th at 9am PT / 12pm EST / 5pm GMT.
Administrators for Google Apps Premier, Education, and Government Editions can use OAuth authorization for Google Apps APIs starting today.For more information about the OAuth standard, visit http://oauth.net.
2013, By: Seo Masterseo 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 Google APIs Client Library for Java: now with OAuth 2.0 2013
Seo Master present to you: 
By Yaniv Inbar, Google APIs Client Team
During Google I/O 2011, we announced a major milestone by releasing the Beta version of the open source Google APIs Client Library for Java. This release included service-specific libraries and samples for Google APIs, built on our new client library generation infrastructure. Since that version 1.4 launch, we’ve been comfortable enough with the stability and features of the library that we want you to start building real production Java 5, Android, and Google App Engine applications and send us your feedback.
Today we are announcing a new milestone for the Java client library. With the version 1.5 release, we’re making available the open source Google OAuth Client Library for Java in Beta, with support for both OAuth 1.0a and OAuth 2.0. OAuth is an open standard for allowing a client application to securely gain access to a user’s private data stored on Google without ever asking for their password. Most Google APIs support OAuth 2.0, and we want to encourage adoption of OAuth 2.0 more widely on the web. That’s why we built this library to work with any API on the web -- not just Google APIs -- that comply with the OAuth specifications. Our current implementation of OAuth 2.0 is based on draft 10, but we will update it soon to the final draft, once it becomes an official standard. We encourage you to try it and send us your feedback.
Here is an example of how easy it is to use the OAuth 2.0 library to make a request using the library for the Google+ API (check out more samples):
We are looking forward to finding out what you can build using these libraries on Google APIs. Please let us know how we can make the libraries easier to use and better suited for your needs.
As we announced at Google I/O 2010, we've been developing APIs that can provide descriptions of themselves via metadata. This new technique makes it easier to create and maintain client libraries that support more languages, work with more APIs, and are easier to use than ever before. This post announces one of several recent major milestones for our client libraries.
Yaniv Inbar is a Senior Software Engineer and Technical Lead of the Google APIs Client Libraries & Tools team. He is the lead developer of the open source Google APIs Client Library for Java. Yaniv has worked at Google for 5 years, and has a total of 12 years industry experience as a software engineer.
Posted by Scott Knaster, Editor
2013, By: Seo Master
By Yaniv Inbar, Google APIs Client Team
During Google I/O 2011, we announced a major milestone by releasing the Beta version of the open source Google APIs Client Library for Java. This release included service-specific libraries and samples for Google APIs, built on our new client library generation infrastructure. Since that version 1.4 launch, we’ve been comfortable enough with the stability and features of the library that we want you to start building real production Java 5, Android, and Google App Engine applications and send us your feedback.
Today we are announcing a new milestone for the Java client library. With the version 1.5 release, we’re making available the open source Google OAuth Client Library for Java in Beta, with support for both OAuth 1.0a and OAuth 2.0. OAuth is an open standard for allowing a client application to securely gain access to a user’s private data stored on Google without ever asking for their password. Most Google APIs support OAuth 2.0, and we want to encourage adoption of OAuth 2.0 more widely on the web. That’s why we built this library to work with any API on the web -- not just Google APIs -- that comply with the OAuth specifications. Our current implementation of OAuth 2.0 is based on draft 10, but we will update it soon to the final draft, once it becomes an official standard. We encourage you to try it and send us your feedback.
Here is an example of how easy it is to use the OAuth 2.0 library to make a request using the library for the Google+ API (check out more samples):
// Set up the HTTP transport and JSON factoryFinally, we are making available a Beta version of the open source Google HTTP Client Library for Java. This is the common HTTP client library that the above two libraries are built on, and is built to work with any API on the web. It features a pluggable HTTP transport abstraction that allows it to work seamlessly on any of the supported Java platforms, support for efficient JSON and XML data models for parsing and serialization, and a pluggable JSON and XML parser so you can use whatever works best for you. Please try it and send us your feedback.
HttpTransport httpTransport = new NetHttpTransport();
JsonFactory jsonFactory = new JacksonFactory();
// Set up OAuth 2.0 access of protected resources
// using the refresh and access tokens, automatically
// refreshing the access token when it expires
GoogleAccessProtectedResource requestInitializer =
new GoogleAccessProtectedResource(accessToken, httpTransport,
jsonFactory, clientId, clientSecret, refreshToken);
// Set up the main Google+ class
Plus plus = new Plus(httpTransport, requestInitializer, jsonFactory);
// Make a request to access your profile and display it to console
Person profile = plus.people().get("me").execute();
System.out.println("ID: " + profile.getId());
System.out.println("Name: " + profile.getDisplayName());
System.out.println("Image URL: " + profile.getImage().getUrl());
System.out.println("Profile URL: " + profile.getUrl());
We are looking forward to finding out what you can build using these libraries on Google APIs. Please let us know how we can make the libraries easier to use and better suited for your needs.
As we announced at Google I/O 2010, we've been developing APIs that can provide descriptions of themselves via metadata. This new technique makes it easier to create and maintain client libraries that support more languages, work with more APIs, and are easier to use than ever before. This post announces one of several recent major milestones for our client libraries.
Yaniv Inbar is a Senior Software Engineer and Technical Lead of the Google APIs Client Libraries & Tools team. He is the lead developer of the open source Google APIs Client Library for Java. Yaniv has worked at Google for 5 years, and has a total of 12 years industry experience as a software engineer.
Posted by Scott Knaster, Editor
2013, By: Seo Master
seo Adding OAuth 2.0 support for IMAP/SMTP and XMPP to enhance auth security 2013
Seo Master present to you: 
By Ryan Troll, Application Security Team
Cross-posted with the Google Online Security Blog
Our users and developers take password security seriously and so do we. Passwords alone have weaknesses we all know about, so we’re working over the long term to support additional mechanisms to help protect user information. Over a year ago, we announced a recommendation that OAuth 2.0 become the standard authentication mechanism for our APIs so you can make the safest apps using Google platforms. You can use OAuth 2.0 to build clients and websites that securely access account data and work with our advanced security features, such as 2-step verification. But our commitment to OAuth 2.0 is not limited to web APIs. Today we’re going a step further by adding OAuth 2.0 support for IMAP/SMTP and XMPP. Developers using these protocols can now move to OAuth 2.0, and users will experience the benefits of more secure OAuth 2.0 clients.
When clients use OAuth 2.0, they never ask users for passwords. Users have tighter control over what data clients have access to, and clients never see a user's password, making it much harder for a password to be stolen. If a user has their laptop stolen, or has any reason to believe that a client has been compromised, they can revoke the client’s access without impacting anything else that has access to their data.
We are also announcing the deprecation of older authentication mechanisms. If you’re using these you should move to the new OAuth 2.0 APIs.
Ryan Troll has been with Google since 2010, and now works with the Application Security Team, focusing on OAuth and 2-Step Verification. When not at work, he spends time with his family, reads, and occasionally plays poker.
Posted by Scott Knaster, Editor
2013, By: Seo Master
By Ryan Troll, Application Security TeamCross-posted with the Google Online Security Blog
Our users and developers take password security seriously and so do we. Passwords alone have weaknesses we all know about, so we’re working over the long term to support additional mechanisms to help protect user information. Over a year ago, we announced a recommendation that OAuth 2.0 become the standard authentication mechanism for our APIs so you can make the safest apps using Google platforms. You can use OAuth 2.0 to build clients and websites that securely access account data and work with our advanced security features, such as 2-step verification. But our commitment to OAuth 2.0 is not limited to web APIs. Today we’re going a step further by adding OAuth 2.0 support for IMAP/SMTP and XMPP. Developers using these protocols can now move to OAuth 2.0, and users will experience the benefits of more secure OAuth 2.0 clients.
When clients use OAuth 2.0, they never ask users for passwords. Users have tighter control over what data clients have access to, and clients never see a user's password, making it much harder for a password to be stolen. If a user has their laptop stolen, or has any reason to believe that a client has been compromised, they can revoke the client’s access without impacting anything else that has access to their data.
We are also announcing the deprecation of older authentication mechanisms. If you’re using these you should move to the new OAuth 2.0 APIs.
- We are deprecating XOAUTH for IMAP/SMTP, as it uses OAuth 1.0a, which was previously deprecated. Gmail will continue to support XOAUTH until OAuth 1.0a is shut down, at which time support will be discontinued.
- We are also deprecating X-GOOGLE-TOKEN and SASL PLAIN for XMPP, as they either accept passwords or rely on the previously deprecated ClientLogin. These mechanisms will continue to be supported until ClientLogin is shut down, at which time support for both will be discontinued.
Ryan Troll has been with Google since 2010, and now works with the Application Security Team, focusing on OAuth and 2-Step Verification. When not at work, he spends time with his family, reads, and occasionally plays poker.
Posted by Scott Knaster, Editor
2013, By: Seo Master
seo OAuth Available for Google Data APIs 2013
Seo Master present to you:
We love open standards, and we've just added support for a new one: OAuth is now supported on all of the Google Data APIs.
OAuth is an open standard for authentication that allows applications to authenticate users without ever directly handling usernames and passwords. Because OAuth is a standard, you can use the same authentication code for any of the Google Data APIs and for APIs from other providers who support OAuth.
To learn more, see the announcement on the Google Data APIs blog.2013, By: Seo Master
We love open standards, and we've just added support for a new one: OAuth is now supported on all of the Google Data APIs.
OAuth is an open standard for authentication that allows applications to authenticate users without ever directly handling usernames and passwords. Because OAuth is a standard, you can use the same authentication code for any of the Google Data APIs and for APIs from other providers who support OAuth.
To learn more, see the announcement on the Google Data APIs blog.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 OAuth access to IMAP/SMTP in Gmail 2013
Seo Master present to you: Google has long believed that users should be able to export their data and use it with whichever service they choose. For years, the Gmail service has supported standard API protocols like POP and IMAP at no extra cost to our users. These efforts are consistent with our broader data liberation efforts.
In addition to making it easier for users to export their data, we also enable them to authorize third party (non-Google developed) applications and websites to access their data at Google. One of the more common examples is allowing a social network to access your address book in order to send invitations to your friends.
While it is possible for a user to authorize this access by disclosing their Google Account password to the third party app, it is more secure for the app developer to use the industry standard protocol called OAuth which enables the user to give their consent for specific access without sharing their password. Most Google APIs support this OAuth standard, and starting today it is also available for the IMAP/SMTP feature of Gmail.
The feature is available in Google Code Labs and we have provided a site with documentation and sample code. In addition, Google has begun working with other companies like Yahoo and Mozilla on a formal Internet standard for using OAuth with IMAP/SMTP (learn more at the OAuth for IMAP mailing list).
One of the first companies using this feature is Syphir, in their SmartPush application for the iPhone, as shown in the screenshots below. Unlike other push apps, Sypher's SmartPush application never sees or stores the user’s Gmail password thanks to this new OAuth support.
We look forward to finalizing an Internet standard for using OAuth with IMAP/SMTP, and working with IMAP/SMTP mail clients to add that support.
2013, By: Seo Master
In addition to making it easier for users to export their data, we also enable them to authorize third party (non-Google developed) applications and websites to access their data at Google. One of the more common examples is allowing a social network to access your address book in order to send invitations to your friends.
While it is possible for a user to authorize this access by disclosing their Google Account password to the third party app, it is more secure for the app developer to use the industry standard protocol called OAuth which enables the user to give their consent for specific access without sharing their password. Most Google APIs support this OAuth standard, and starting today it is also available for the IMAP/SMTP feature of Gmail.
The feature is available in Google Code Labs and we have provided a site with documentation and sample code. In addition, Google has begun working with other companies like Yahoo and Mozilla on a formal Internet standard for using OAuth with IMAP/SMTP (learn more at the OAuth for IMAP mailing list).
One of the first companies using this feature is Syphir, in their SmartPush application for the iPhone, as shown in the screenshots below. Unlike other push apps, Sypher's SmartPush application never sees or stores the user’s Gmail password thanks to this new OAuth support.
We look forward to finalizing an Internet standard for using OAuth with IMAP/SMTP, and working with IMAP/SMTP mail clients to add that support.
2013, By: Seo Master
seo OAuth 2.0 Playground: new features 2013
Seo Master present to you: 
By Nicolas Garnier, Developer Relations
Last November, we launched the OAuth 2.0 Playground, a tool enabling you to easily experiment with the OAuth 2.0 protocol and APIs that use the protocol.
Since then, we've continued adding new features to improve the developer experience and increase the versatility of the tool.
Below is a list of features that we added since the initial release of the OAuth 2.0 playground.
Support for the OAuth 2.0 Client-side flow
You can now use the playground to experiment with the OAuth 2.0 Client-side flow by simply changing a setting in the OAuth 2.0 configuration dialog. Once set, every subsequent authorization request is performed using the client-side flow, and the playground’s interface and logic adapt accordingly.
Support for newer OAuth 2.0 drafts
We have added a setting to change the location of the access token in authorized requests to the APIs. We added support for the authorization header with a
Display available API operations
You can now easily display all the operations that are available using your current access token. After clicking the Find available Request URIs button, the operations along with their associated HTTP Methods and URIs are displayed on the right-hand side. This should help you quickly set up your request to the Google APIs without needing to search through the online documentation.
Note: the technique used to find the list of operations available given an access token is described in this blog post.
Support for the
The playground now also lets you try the new Google-specific settings of the OAuth 2.0 flow: the
Automatically refresh access tokens
If a refresh token is available, you can enable a feature that will automatically refresh the access token shortly before it expires. This is convenient if you are using the playground for a long time or if you are re-initializing the playground using the deep-link feature.
Selectable links in responses
Clicking any links in an HTTP response will populate the request URI field so that you can quickly and conveniently set up the playground for the next operation.
If you have any feedback or would like to get in touch with us, please don’t hesitate to post on the OAuth 2.0 Playground forum.
Nicolas Garnier joined Google Developer Relations in 2008 and lives in Zurich. He is a Developer Advocate focusing on Google Apps and Web APIs. Before joining Google, Nicolas worked at Airbus and at the French Space Agency where he built web applications for scientific researchers.
Posted by Scott Knaster, Editor
2013, By: Seo Master
By Nicolas Garnier, Developer RelationsLast November, we launched the OAuth 2.0 Playground, a tool enabling you to easily experiment with the OAuth 2.0 protocol and APIs that use the protocol.
 |
| The OAuth 2.0 Playground |
Since then, we've continued adding new features to improve the developer experience and increase the versatility of the tool.
Below is a list of features that we added since the initial release of the OAuth 2.0 playground.
Support for the OAuth 2.0 Client-side flow
You can now use the playground to experiment with the OAuth 2.0 Client-side flow by simply changing a setting in the OAuth 2.0 configuration dialog. Once set, every subsequent authorization request is performed using the client-side flow, and the playground’s interface and logic adapt accordingly.
 |
| Setting the OAuth flow type |
Support for newer OAuth 2.0 drafts
We have added a setting to change the location of the access token in authorized requests to the APIs. We added support for the authorization header with a
Bearer prefix and the access_token URL parameter locations. This makes the playground compatible with most APIs supporting OAuth 2.0 drafts 10 to 25. |
| Setting the access token location |
Display available API operations
You can now easily display all the operations that are available using your current access token. After clicking the Find available Request URIs button, the operations along with their associated HTTP Methods and URIs are displayed on the right-hand side. This should help you quickly set up your request to the Google APIs without needing to search through the online documentation.
 |
| Displaying the available endpoints after being authorized for the Google+ API |
Note: the technique used to find the list of operations available given an access token is described in this blog post.
Support for the
access_type and the approval_prompt parametersThe playground now also lets you try the new Google-specific settings of the OAuth 2.0 flow: the
access_type and the approval_prompt parameters of the authorization request. |
| Setting the access type and whether or not to force the approval prompt |
Automatically refresh access tokens
If a refresh token is available, you can enable a feature that will automatically refresh the access token shortly before it expires. This is convenient if you are using the playground for a long time or if you are re-initializing the playground using the deep-link feature.
 |
| Enabling the access token auto-refresh feature |
Selectable links in responses
Clicking any links in an HTTP response will populate the request URI field so that you can quickly and conveniently set up the playground for the next operation.
 |
| Clicking a link populates the Request URI field |
If you have any feedback or would like to get in touch with us, please don’t hesitate to post on the OAuth 2.0 Playground forum.
Nicolas Garnier joined Google Developer Relations in 2008 and lives in Zurich. He is a Developer Advocate focusing on Google Apps and Web APIs. Before joining Google, Nicolas worked at Airbus and at the French Space Agency where he built web applications for scientific researchers.
Posted by Scott Knaster, Editor
2013, By: Seo Master
seo Service Accounts have arrived 2013
Seo Master present to you: 
By Justin Smith, Product Manager
Starting today, Google supports Service Accounts, which provide certificate-based authentication for server-to-server interactions. This means, for example, that a request from a web application to Google Cloud Storage can be authenticated via a certificate instead of a shared key. Certificates offer better security properties than shared keys and passwords, largely because they are not human-readable or guessable.
Service accounts are currently supported by the following Google developer services:
This feature is implemented as an OAuth 2.0 flow and is compliant with draft 25 of the OAuth 2.0 specification. An application implements the following steps to authenticate with a Service Account:
If you’re a Google App Engine developer, all this might sound similar to what is described in these articles: App Engine & Storage, App Engine & Prediction. Service Accounts generalize this App Engine capability by making it available to other server-side platforms. When using another server-side platform, you can create a Service Account through the Google APIs Console. See the Google APIs Console documentation for more information on creating a Service Account.
As always, we welcome and appreciate feedback. Please post any questions or comments to the OAuth 2.0 Google group.
Justin Smith is a Google Product Manager and works on authentication and authorization technologies. He enjoys woodworking, cycling, country music, and the company of his wife and newborn daughter (not in that order).
Posted by Scott Knaster, Editor
2013, By: Seo Master
By Justin Smith, Product Manager
Starting today, Google supports Service Accounts, which provide certificate-based authentication for server-to-server interactions. This means, for example, that a request from a web application to Google Cloud Storage can be authenticated via a certificate instead of a shared key. Certificates offer better security properties than shared keys and passwords, largely because they are not human-readable or guessable.
Service accounts are currently supported by the following Google developer services:
- Google Cloud Storage
- Google Prediction API
- Google URL Shortener
- Google OAuth 2.0 Authorization Server
- Google APIs Console
- Google APIs Client Libraries for Python, Java, and PHP
This feature is implemented as an OAuth 2.0 flow and is compliant with draft 25 of the OAuth 2.0 specification. An application implements the following steps to authenticate with a Service Account:
- Generate a JSON structure.
- Sign the JSON structure with a private key, and encode it as a JSON Web Token (JWT).
- Send the JWT to Google’s OAuth 2.0 Authorization Server in exchange for an access token.
- Send the access token to Google Cloud Storage or the Google Prediction API.
If you’re a Google App Engine developer, all this might sound similar to what is described in these articles: App Engine & Storage, App Engine & Prediction. Service Accounts generalize this App Engine capability by making it available to other server-side platforms. When using another server-side platform, you can create a Service Account through the Google APIs Console. See the Google APIs Console documentation for more information on creating a Service Account.
As always, we welcome and appreciate feedback. Please post any questions or comments to the OAuth 2.0 Google group.
Justin Smith is a Google Product Manager and works on authentication and authorization technologies. He enjoys woodworking, cycling, country music, and the company of his wife and newborn daughter (not in that order).
Posted by Scott Knaster, Editor
2013, By: Seo Master
seo Best Practices for User Authentication 2013
Seo Master present to you: By now, many of you have seen our recent announcement regarding 2-step verification for Google Accounts. It’s an optional way of protecting your Google Account from unauthorized access, providing a level of security beyond that of a password alone. The initial announcement did not detail the impact enabling 2-step verification has on programmatic account access from code written against one of Google’s official APIs. We want to go into some more detail regarding the implications of 2-step verification on various authentication (and authorization) techniques, and offer best practices that you as a developer should follow.
There are three forms of authentication supported by almost all of Google’s APIs. AuthSub and OAuth (either version 1 or the newer OAuth 2) are similar web-based authentication mechanisms in which the user logs in on a web page hosted by Google. The other approach to authentication, ClientLogin, relies on your application soliciting the user’s account address and password, and then sending that information to Google.
If your code uses AuthSub or OAuth, then you don’t have to do anything special to accommodate users who have opted-in to 2-step verification. The web-based login flow currently allows users to enter both their normal passwords as well as the additional verification code, and this extra step is transparent to you as the developer.
ClientLogin, however, does not fare as well for accounts that have 2-step verification enabled. There is no concept of an additional verification code in the ClientLogin process, and a user’s account address and password are no longer sufficient for authenticating them once 2-step verification is turned on. If you make a ClientLogin authentication request for such an account, you’ll get back an
There are two solutions to these failed ClientLogin attempts. The first solution, which does not require changing any existing code, is to ask your users to generate an application-specific password and to provide that, instead of their Google Account passwords, when making your ClientLogin request. You can point your users to this article for a full explanation of how application-specific passwords work.
The second, and recommended, solution requires some work on your part as a developer: moving away from ClientLogin completely, in favor of OAuth 2. If your code runs as part of a web application, then OAuth 2’s web-based login flow is trivial to integrate. Even applications that are installed on a user’s computer or other device can leverage OAuth 2, though. This guide explains how to launch a web browser to handle the login process, and then redirect control back to your application.
While it may take some effort to migrate your code away from ClientLogin, your users will be grateful that you did. Even those who haven’t enabled 2-step verification will benefit from entering their credentials on a web page accessed via HTTPS and hosted by Google, as opposed to sharing their password information directly with your third party code.
2013, By: Seo Master
There are three forms of authentication supported by almost all of Google’s APIs. AuthSub and OAuth (either version 1 or the newer OAuth 2) are similar web-based authentication mechanisms in which the user logs in on a web page hosted by Google. The other approach to authentication, ClientLogin, relies on your application soliciting the user’s account address and password, and then sending that information to Google.
If your code uses AuthSub or OAuth, then you don’t have to do anything special to accommodate users who have opted-in to 2-step verification. The web-based login flow currently allows users to enter both their normal passwords as well as the additional verification code, and this extra step is transparent to you as the developer.
ClientLogin, however, does not fare as well for accounts that have 2-step verification enabled. There is no concept of an additional verification code in the ClientLogin process, and a user’s account address and password are no longer sufficient for authenticating them once 2-step verification is turned on. If you make a ClientLogin authentication request for such an account, you’ll get back an
HTTP 403 error response from our servers with the following in error included in the response body:
Error=BadAuthentication
Info=InvalidSecondFactor
There are two solutions to these failed ClientLogin attempts. The first solution, which does not require changing any existing code, is to ask your users to generate an application-specific password and to provide that, instead of their Google Account passwords, when making your ClientLogin request. You can point your users to this article for a full explanation of how application-specific passwords work.
The second, and recommended, solution requires some work on your part as a developer: moving away from ClientLogin completely, in favor of OAuth 2. If your code runs as part of a web application, then OAuth 2’s web-based login flow is trivial to integrate. Even applications that are installed on a user’s computer or other device can leverage OAuth 2, though. This guide explains how to launch a web browser to handle the login process, and then redirect control back to your application.
While it may take some effort to migrate your code away from ClientLogin, your users will be grateful that you did. Even those who haven’t enabled 2-step verification will benefit from entering their credentials on a web page accessed via HTTPS and hosted by Google, as opposed to sharing their password information directly with your third party code.
2013, By: Seo Master
seo Making auth easier: OAuth 2.0 for Google APIs 2013
Seo Master present to you: One of the most exciting things about the architecture of the web is how easily it supports mashups—URLs, IFRAMEs, XHR, and more make it easy to build great new services on top of building blocks from others. As more and more people use the web for non-public data, we need new techniques to secure those building blocks. That’s where OAuth comes in—an open, standard way for users to grant permission for an application to access part of their account.
Since we announced support for OAuth in 2008, we've seen tremendous usage growth in our APIs that require user authorization, like Calendar and Docs. While the spec isn't completely finalized, Google is pleased to announce our experimental support of an easier way for developers to obtain user authorization for our APIs: OAuth 2.0 with bearer tokens. Whether you use our updated client libraries or just write to the protocol, you should be able to do more with less code.
In addition to supporting a simplified protocol, we're also introducing a simpler, cleaner consent page for OAuth 2.0:
Google believes in open systems that give users value, transparency and control. We hope the OAuth 2.0 protocol helps developers deliver just that: powerful applications that make use of user data without compromising on safety or security. Check out our documentation to get started with OAuth 2.0.
2013, By: Seo Master
Since we announced support for OAuth in 2008, we've seen tremendous usage growth in our APIs that require user authorization, like Calendar and Docs. While the spec isn't completely finalized, Google is pleased to announce our experimental support of an easier way for developers to obtain user authorization for our APIs: OAuth 2.0 with bearer tokens. Whether you use our updated client libraries or just write to the protocol, you should be able to do more with less code.
In addition to supporting a simplified protocol, we're also introducing a simpler, cleaner consent page for OAuth 2.0:
Google believes in open systems that give users value, transparency and control. We hope the OAuth 2.0 protocol helps developers deliver just that: powerful applications that make use of user data without compromising on safety or security. Check out our documentation to get started with OAuth 2.0.
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