Posted by Vartika Agarwal, Technical Program Manager, Identity & Authentication, and Wesley Chun, Developer Advocate, Google

As we indicated several years ago, we are moving away from the OAuth 1.0 protocol in order to focus our support on the current OAuth standard, OAuth 2.0, which increases security and reduces complexity for developers. OAuth 1.0 (3LO)1 was shut down on April 20, 2015. During this final phase, we will be shutting down OAuth 1.0 (2LO) on October 20, 2016. The easiest way to migrate to the new standard is to use OAuth 2.0 service accounts with domain-wide delegation.

If the migration for applications using these deprecated protocols is not completed before the deadline, those applications will experience an outage in their ability to connect with Google, possibly including the ability to sign-in, until the migration to a supported protocol occurs. To avoid any interruptions in service for your end-users, it is critical that you work to migrate your application(s) prior to the shutdown date.

With this step, we continue to move away from legacy authentication/authorization protocols, focusing our support on modern open standards that enhance the security of Google accounts and that are generally easier for developers to integrate with. If you have any technical questions about migrating your application, please post them to Stack Overflow under the tag google-oauth.


1 3LO stands for 3-legged OAuth: there's an end-user that provides consent. In contrast, 2-legged (2LO) doesn’t involve an end-user and corresponds to enterprise authorization scenarios such as enforcing organization-wide policy control access.

Easy access and single sign-on to applications has been a cornerstone of the Apps Marketplace since it launched. When a user clicks on an app in the Google Apps universal navigation (the “more” menu), they’re immediately signed into the app resulting in the same experience as when switching between Gmail, Calendar, and other Google apps. However, sometimes users navigate directly to the homepage of the app and want to sign in there. Handling this case while still maintaining a great user experience can be challenging.

To help, we suggest that Marketplace vendors evaluate the Google Identity Toolkit (GITKit). The toolkit drastically improves the sign-in experience for Google Apps users, as well as for users of popular free webmail services such as Gmail, Yahoo! Mail, Hotmail, and AOL Mail.

The biggest improvement in the sign-in flow is that after a user has logged into your website once, their return experience will be as simple as seeing the account (or accounts) they have used with your site and clicking the one they want to use.

For example, the user Bonnie might use the sassyapp.com app for both her main job, as well as for a small business she runs with her husband Clyde. Whenever Bonnie or Clyde need to sign in to sassyapp.com, they simply click the account they want to use.


If the user does not see their account listed, then they go through a one-time flow to add the account which sends them to the screen below. A Google Apps user can either click the Gmail button or type their email address. For users who cannot login with an identity provider, they will be asked to either enter their password or create a new account after entering their email address.



This user experience is based on an industry technique called an account chooser. In fact, Google is in the process of replacing its own login box with an account chooser and you can opt-in to start using it on Google yourself.

The Google Identity Toolkit (GITkit) can be used by any website, but is particularly useful for Apps Marketplace vendors. The toolkit is an external REST-based API built on the exact same infrastructure that Google uses to be a relying party, and includes a JavaScript widget for the same account chooser experience that you can opt-in to use on Google.

For more information, refer to the GITkit and Apps Marketplace documentation.

Eric Sachs

Eric is a Product Manager for Google Security and board member of The OpenID Foundation. He has more than 15 years of experience in the areas of user identity and security for hosted Web applications. During his five-plus years at Google, he has worked as a Product Manager for many services, including the Google Account login system, Google Apps for Your Domain, orkut.com social network, Google Health, Google Security, and Internal Systems.

The Google Apps Marketplace is a storefront for Google Apps customers to discover, purchase, deploy and manage web applications which are integrated with Google Apps. These applications are typically used from desktops and laptops, but many vendors on the Apps Marketplace have also optimized the experience for their users who are on-the-go. There are several different strategies for enabling a mobile workforce, and each requires a different approach to authentication and authorization.

Lightweight: Synchronize Contacts, Calendars and Docs with Google Apps

Google has written applications and synchronization clients to help ensure that the core Google Apps data is available to users on their mobile devices, whether they’re on their mobile phones or tablets. By storing contacts, dates and documents from your application in Google Apps using the application APIs, you can leverage these features to provide a mobile view for your users.

Since you’re only accessing the application APIs on your web application’s server, and the user has already linked up their mobile device to their Google account, there are no special techniques for authentication and authorization when using this lightweight approach.

Standards-based: Build a mobile-optimized web application

With the latest advances in HTML5 web technologies such as offline and local storage, it’s possible to build mobile interfaces for business apps which are full-featured and accessible to users on many devices. The primary goal in building the mobile web application is to optimize the user experience for different input devices, form factors and limitations in network availability and bandwidth.

Because the application is in a web browser, most of the changes to implement are in the frontend-- HTML, JavaScript and CSS. User authentication and data authorization continue to use the same OpenID and OAuth technologies as are used for the desktop/laptop version of the application.

Device-custom: Build native companion apps for mobile devices

Does your application need access to hardware-specific APIs which are not available in a web browser, or do you feel a great user experience can only be achieved using native code? Several Apps Marketplace vendors have built native applications for popular mobile platforms like Android and iOS. Although it takes considerably more effort to build multiple native applications to cover the major platforms, these vendors can also take advantage of the additional distribution channels offered by mobile stores.

Authentication and authorization are often challenging for developers building native mobile applications because they cannot simply ask users for a password if their app supports single-sign on to Google with OpenID. We recently published an article describing a technique using an embedded webview for accomplishing OpenID authentication in mobile apps. This article includes references to sample code for Android and iOS.




Many Project Management applications, like Manymoon, store important dates on Google Calendar. These dates are then available on mobile devices.

GQueues has a HTML5 mobile app. Their founder has written about why they used this technique.

Native applications, such as the OpenID Sample Store displayed, can use an embedded webview to authenticate users.




Ryan Boyd   profile | twitter | events

Ryan is a Developer Advocate on the Google Apps Marketplace team, helping businesses build applications integrated into Google Apps. Wearing both engineering and business development hats, you'll find Ryan writing code and helping businesses get to market with integrated features.


Want to weigh in on this topic? Discuss on Buzz

One of the core requirements of preparing an application for launch on the Google Apps Marketplace is integrating with OpenID-based Single Sign-On. This enables Google Apps users to access your application without creating and maintaining additional credentials. This lowers the barrier to entry for your application and creates a seamless on-boarding flow.

In addition to making your app easier to use, OpenID can improve security for applications by reducing the number of places you need to enter a password. Of course, it’s also important to strengthen the security of the places you are entering your password, and yesterday’s launch of Two-step verification does just that.

Until yesterday, Google Apps customers using Google Apps’ built-in authentication mechanisms needed to provide a username and password (something they knew) to log in. Our launch of 2-factor authentication, which we’re calling Two-step verification, enables users of Premier, Education and Government Editions to additionally require having something in possession- a mobile phone- to log in.

So, if you’re a Marketplace developer and your customer asks you if your app supports 2-factor auth, you can answer an emphatic “yes” and send them over to the Marketplace to add your app to their domain.

Want to weigh in on this topic? Discuss on Buzz

Editor's Note: Jeff Morgan is a Senior Technical Consultant at Appirio, a cloud solution provider which creates products and delivers services . He’s worked with many Google Data APIs, so we’re excited to publish his insights on the various authentication choices.

As developers using the Google Data APIs, one of the first challenges we tackle is learning and sorting through the Google Data authentication schemes. AuthSub, OAuth, ClientLogin, OpenID+OAuth, and so on. Perhaps you may be developing a Google App Engine web application for the first time and want access to a user's Google Calendar. Maybe you are building a data processing application that requires access to a Google user's data. If you are familiar with the Google Data APIs you likely know that there are many authentication options available depending on the API. So how do you decide? The best place to start is the Getting Started with Account Authorization guide. Also, the Authentication in Google Data Protocol page provides detail on the various authentication methods. This post provides references to many existing resources and some additional things to consider to help you decide which authentication method to use for your application.

Does your application need end user permission to access their Google data?

When developing web applications, developers are sometimes faced with deciding between AuthSub or OAuth. However, the first question should be, "Who will be granting permission to the user's Google data?" If the end users are Google Apps users then most likely it will be an administrator granting access. Frequently developers ask the same question in another way, "Should I use 3-legged or 2-legged authentication?" Ideally, from a Google Apps user experience perspective, it is better to use 2-legged OAuth. This way the application is granted access to a user's Google Apps data at the administrator level. The end user can start to use the application and the trust has already been established by an administrator. If you are developing a Marketplace application then it is very likely you will not need to engage in the 3-legged authentication dance.
However, if you are writing an application that is wide open to anyone with a Google account, let the 3-legged dance begin. Both AuthSub and OAuth for Web Applications are designed for this purpose. However, the behavior and look and feel for each is slightly different. Both ultimately allow the user to grant your application access to their data, but knowing the differences helps you make the best choice. Here is an article that covers the topic and should help you choose. It has color coded highlights that compare the two.

Some general rules follow when choosing an authentication method:
End UserAuthentication
Google User (regular)AuthSub or 3-Legged OAuth (3LO)
Googe Apps User (hosted)2-Legged OAuth (2LO)
No end user2LO or ClientLogin


Gadgets

Again there are different options for choosing Google Data authentication from a Gadget container. The first option to consider is OAuth Proxy for Gadgets. OAuth proxy is a 3-legged dance asking the end user for permission to access their data. Once access has been granted then the gadget developer can use the gadgets.io.makeRequest()method to make the Google Data API calls. Most likely you will want the JSON response from the feed so remember to add the ?alt=json URL parameter. For more information and code examples on OAuth Proxy see Writing OAuth Gadgets.

For Marketplace Gadgets another authentication option is available and uses OpenID. This option is used to authenticate the user and determine identity only and it does not provide authorization for API access. After the user is authenticated, server-to-server calls are used to make the requests, authorized via 2-legged OAuth and specifying the xoauth_requestor_id based on the authenticated user from OpenID. For more information on this approach see the Marketplace Best Practices page.


Secure Storage of Credentials

Adding layers of security is a common approach to to making data more secure. Google does provide various layers by providing different authentication and authorization methods. Registering web applications, supporting digital certificates, support for industry standards, (SAML, OAuth, OpenID) all help in providing security. However, one of the most common mistakes we can make is not taking care to protect important credentials. When working with Google Data ClientLogin and 2-legged OAuth, these credentials can be keys to the kingdom (e.g. administrator credentials or domain OAuth consumer secret) and therefore should be protected at all costs. Access to these credentials can potentially open the entire Google Apps domain data for the authorized services. This could have tremendous impact especially if you are maintaining 2-legged OAuth credentials for domains that have granted your application access, e.g. a Marketplace application. Therefore it is risky practice to embed them in source code or even a configuration file. Consider using an approach that allows you to enter credentials at runtime and store in memory or use your favorite method for secure storage of these important credentials.


Google Apps Marketplace

With the March announcement of the Google Apps Marketplace, the decision making process may have become a little easier. OpenID+OAuth and 2-Legged OAuth are the schemes that are supported and likely will be used if your Marketplace application needs access to Google Apps data; which is very likely. You’ll notice that the Marketplace has embraced the open standards of OpenID and OAuth. While AuthSub and ClientLogin are proprietary to Google, they will likely not be useful in your Marketplace application.


ClientLogin

If your application needs to create or make modifications to user accounts (using the Provisioning API) then your only current option is ClientLogin. But a common oversight is to not reuse the access token. Without proper reuse of this token, eventually your application will force the account into a CAPTCHA state which can easily be avoided if the access token is used for subsequent ClientLogin authentication requests. It is best to keep this token cached in memory and renew the token in some configured frequency/timeout.

Summary

This post covered some important considerations for selecting a Google Data authentication method for your application. If you are new to Google Data authentications and want to have a better overall understanding then start with the Getting Started with Account Authorization guide. No matter which approach you choose make sure that accessing users data is done is a secure user friendly way.

References

Google Data authentication is a vast topic. For your convenience here are a list of resources.

Google Data Authentication - Start Here
Getting Started with Account Authorization
Authentication in the Google Data Protocol
OAuth
OAuth in the Google Data Protocol Client Libraries
OAuth for Web Applications
OAuth for Installed Applications
OAuth API Reference
Using OAuth with the Google Data APIs
Google Data API Tips - OAuth
OAuth Playground
OAuth-enabled http test client: oacurl
Gadgets
Authentication for Gadgets
Writing OAuth Gadgets
Fetching Remote Content
Creating a Google Data Gadget
JavaScript client library API reference
Using JSON with Google Data APIs
OAuth Enabled Gadgets on OpenSocial enabled Social Networks
Registration
Registration for Web-Based Applications
OpenID
Federated Login Service for Google Apps
OpenID+OAuth
Sharing and previewing Google Docs in Socialwok: Google Data APIs
Step2 Code Project
OpenID OAuth Extension
ClientLogin
ClientLogin in the Google Data Protocol Client Libraries
ClientLogin for Installed Applications
Google Data API Blog - ClientLogin
AuthSub
AuthSub Authentication for Web Applications
Using AuthSub in the Google Data Protocol JavaScript Client Library
Google Data API Tips - AuthSub
Google I/O
OpenID-based single sign on and OAuth data access for Google Apps

Want to weigh in on this topic? Discuss on Buzz

Editor's Note: This post was written by Zhenya Grinshteyn and Tom Jacobs of Expensify. We invited Expensify to share their experience with the Google Apps Marketplace.

Expensify does expense reports that don't suck by importing expenses and receipts from your credit cards and mobile phones, submitting expense reports through email, and reimbursing online with QuickBooks and direct deposit.

The Foundation: Single Sign-On

We were really excited when Google approached us to be a launch partner for their new Google Apps Marketplace because tons of our customers use Google Apps -- including us! We have long wanted to put an 'Expenses' link up there next to Mail and Documents, and now we had our chance.


To do that, we installed the JanRain PHP OpenID library with the Google Apps Discovery extension. We’d already implemented Gmail OpenID and ironed out the kinks related to having multiple logins to a single account, so implementing this was a very straightforward process.

Lessons Learned

We quickly learned that while single sign-on is awesome, there was a high drop-off rate among admins installing Expensify into their domain. Digging deeper we determined it was due to the setup process being split: part of the setup was done from within Google Apps, but the final part had to be completed by signing in to our site. Not only that, a major part of the setup process was laboriously entering their employee’s emails. We decided to address each in turn by creating a setup wizard and importing the domain’s email list. We approached this change in two major ways:

First, when the Google Apps admin installs the Expensify application, we created a custom configuration step that creates what we call an 'expense policy'. This governs everything from who is part of the company, who can approve expenses, and ultimately who exports to QuickBooks to keep the general ledger in check. Previously this step had to be done after the application was already installed, usually when the admin first signed in. By making this step part of the install process, the entire setup felt much more intuitive and resulted in a higher completion rate.

Second, we used the Zend framework to connect to the Google Apps Provisioning API to fill the new expense policy with a list of all existing employees. This saved a ton of typing and resulted in a vast reduction in the time it took to deploy Expensify to the full company. With everything else in place, the code we used to do this looked something like this:
$oauthOptions = array(
'requestScheme' => Zend_Oauth::REQUEST_SCHEME_HEADER,
'version' => '1.0',
'signatureMethod' => 'HMAC-SHA1',
'consumerKey' => $CONSUMER_KEY,
'consumerSecret' => $CONSUMER_SECRET
);
$consumer = new Zend_Oauth_Consumer($oauthOptions);
$token = new Zend_Oauth_Token_Access();
$httpClient = $token->getHttpClient($oauthOptions);
$service = new Zend_Gdata_Gapps($httpClient, $domain );
$users = $service->retrieveAllUsers();
All of the users’ names and emails are presented in a table of employees that the person installing the app can use to set roles and quickly build an approval tree for all expenses.


Once the setup is completed, we automatically create accounts for all of the selected employees and send out a brief email with tips to get started.

Results: 3.5x more users sign up

Overall it was a fast and painless process, has increased the flow of high-quality leads, and has accelerated their rate of converting into real users. Domain admins now sign up 3.5x more users right away than they have been using the previous two-part setup! Feel free to install our app to see how the setup process works, and respond to this post with questions about your implementation -- we'll try to help out as best we can. And of course if you're still doing your expense reports the old sucky way, please come visit our website (Expensify.com) and we'd be happy to help ease your pain. Thanks for reading, let me know if there's anything I can help clarify!

Want to weigh in on this topic? Discuss on Buzz

Editor's Note: This post was written by Gilad Goraly from ScheduleOnce, a company that provides meeting scheduling solutions for Google Calendar. We invited ScheduleOnce to share their experiences building an application on top of Google Apps utilizing some of our APIs.

ScheduleOnce provides meeting scheduling solutions for organizations using Google Apps. Our solutions extend Google Calendar to support cross-organizational scheduling and include private labeling and robust scheduling features. Since our solution is not a standalone application but an add-on to a calendaring and messaging platform, we were looking to integrate it with a platform that is open and inviting for third party vendors. Google Apps was the natural choice.

Google Calendar does a great job when it comes to scheduling meetings with members inside the organization. The free/busy view allows you to see attendee availability and select a time that is good for all. But what do you do when the meeting involves one or more external attendees? With ScheduleOnce it is possible to see the availability of all attendees, both internal and external, across domains, in one simple free/busy interface. The meeting organizer then selects a time and schedules the meeting. It is that simple. Now let’s see what’s behind the scenes and why we chose to develop it for Google Apps.

For the solution to work effectively it should be completely integrated into the user’s messaging and calendaring environment. This is why we chose to work with Google. Google Apps is an open messaging and calendaring platform with a convenient integration framework. We have the following integration points with Google Apps:

  1. The Google Apps Marketplace installation process adds a link in Google’s universal navigation and enables Single Sign On (SSO).

  2. The Google Gadget framework is used to include a gadget in Google Calendar and in Gmail.

  3. The Google Calendar API is used to seamlessly integrate with the user’s calendar.

Now lets look at each integration point and some of the APIs we used to make ScheduleOnce work seamlessly with Google Apps.

Installation from the Google Apps Marketplace

The new Google Apps Marketplace installation process provides two major benefits:
  1. A quick and easy installation process and a link in Google’s universal navigation

  2. Single Sign On (SSO)

Installation process

The Google Apps administrator follows a simple installation wizard. During this process the following is done by ScheduleoOnce:
  1. The Administrator approves a Two Legged OAuth (2LO) calendar API permission for all domain users. This means that ScheduleOnce can access the calendar API of every user in the domain without requiring the user to re-enter their credentials. This is very convenient for the user.

  2. Every user in the domain automatically gets a link to a Personal ScheduleOnce Dashboard on his Google universal navigation. This is set in the installation manifest:
    <Extension id="oneBarLink" type="link">
    <Name>ScheduleOnce</Name>
    <Url>http://apps.scheduleonce.com/render.aspx?source=${DOMAIN_NAME}&amp;page=dashboard</Url>
    </Extension>
  3. The administrator selects a URL and a logo for the application. We use the SSO and ${DOMAIN_NAME} parameter to verify that the user is part of the domain so one cannot maliciously create ScheduleOnce instances. We also use the ${DOMAIN_NAME} parameter for presenting the domain custom logo:
    https://www.google.com/a/${DOMAIN_NAME}/images/logo.gif?alpha=1

Single Sign On (SSO)

During the installation process our URL is "white listed" at Google so we can authenticate the user by their Open ID. Behind the scenes, ScheduleOnce handles the authentication for the user as described here. In addition, the administrator grants permission to access the user calendar API for all the users in the domain. Since authentication for API access is done using 2-Legged-OAuth (2LO) we can directly connect to the user’s calendar.

On the server side there is a service that handles the 2LO requests
// Create a service for making 2LO requests
GOAuthRequestFactory requestFactory = new GOAuthRequestFactory("cl", "yourCompany-YourAppName-v1");
requestFactory.ConsumerKey = <CONSUMER_KEY>;
requestFactory.ConsumerSecret = <CONSUMER_SECERT>;
CalendarService service = new CalendarService(requestFactory.ApplicationName);
service.RequestFactory = requestFactory;
SSO and 2LO provide the needed security with the convenience of a transparent login. With this combination the ScheduleOnce application looks like any other Google Apps application. When trying to access the ScheduleOnce application before authenticating with Google Apps, the user will get the normal Google Apps login (so no one outside the domain can login). When entering the ScheduleOnce application from one of the Google Apps entry points (Google’s universal navigation or one of the gadgets) then the login is done behind the scenes and it is transparent to the user.

Gadgets in Google Calendar, Gmail and the Start Page

We used an OpenSocial gadget for providing meeting management functionality. Authentication here is a bit trickier since it should be done without the user doing anything actively. To identify the user we used SSO and Open ID, allowing the gadget to be installed on any Google Apps gadget container (such as Google Calendar or Gmail).

Gadget initialization includes UI and OpenSocial data request:
function initGadget(){
//Initializing the gadget tabs
tabs.addTab("Pending", {
contentContainer: document.getElementById("pending_id"),
callback: callback
});
tabs.addTab("Scheduled", {
contentContainer: document.getElementById("scheduled_id"),
callback: callback
});
tabs.displayTabs(false);
refresh();

//Initializing the OpenSocial data request
var idspec = opensocial.newIdSpec({ "userId" : "OWNER"});
var req = opensocial.newDataRequest();
req.add(req.newFetchPersonRequest(opensocial.IdSpec.PersonId.OWNER), "get_owner");
req.send(openSocialResponse);
}
where the POST request looks something like this:
function makePOSTRequest(){
var url = baseURL + "GadgetHandler.aspx";
var postdata = {opensocialid : openSocialID};
var params = {};
postdata = gadgets.io.encodeValues(postdata);
params[gadgets.io.RequestParameters.METHOD] = gadgets.io.MethodType.POST;
params[gadgets.io.RequestParameters.POST_DATA]= postdata;
params[gadgets.io.RequestParameters.CONTENT_TYPE] = gadgets.io.ContentType.TEXT;
gadgets.io.makeRequest(url, responseHandler, params);
}
When the gadget runs it loads a hidden iframe to check if the user (by his Open ID) is authenticated on the server. If the user is not authenticated, authentication is done behind the scenes and the user’s Open ID is added to a temporary application object. If the user’s Open ID mapping exists on the application object it means the user is authenticated and can work freely in the ScheduleOnce application.

Integration with Google Calendar

Google Calendar is accessed using the Google Calendar API. Three major functions are used:
  1. Getting the user's busy times: Since availability is dynamic and dependent on the current calendar status we update it every time it is needed. This ensures there will never be any double booking in the user’s calendar.
    // Retrieving the calendar events for a time frame
    EventQuery query = new EventQuery();
    string uriString = "https://www.google.com/calendar/feeds/" + username + "/private/full?ctz=utc";

    query.Uri = new Uri(uriString);
    query.StartTime = <time frame start>;
    query.EndTime = <time frame end>;

    EventFeed calFeed = service.Query(query);
    AtomEntryCollection entryColl = calFeed.Entries;
  2. Creating a calendar with tentative meeting times: ScheduleOnce cannot "lock" certain timeframes until the scheduling process is over. For this reason we create a tentative meetings calendar that can be used to see times that were proposed for a meeting.
    // Creating a calendar
    CalendarEntry calendar = new CalendarEntry();
    calendar.Title.Text = <calendar title>;
    calendar.Summary.Text = <calendar description>;
    calendar.TimeZone = <calendar timezone>;
    Uri postUri = new Uri("https://www.google.com/calendar/feeds/default/owncalendars/full");
    CalendarEntry createdCalendar = (CalendarEntry)service.Insert(postUri, calendar);
  3. Scheduling the meeting and sending the invitation via Google Calendar: When the meeting organizer schedules the meeting, a meeting entry is created in his calendar and meeting invitations are sent to all attendees.
    // Creating a meeting
    EventEntry entry = new EventEntry();
    entry.Title.Text = <meeting Title>;
    When eventTime = new When(<meeting startTime>, <meeting endTime>);
    entry.Times.Add(eventTime);
    Uri postUri = new Uri("https://www.google.com/calendar/feeds/" + username + "/private/full?ctz=utc");
    AtomEntry insertedEntry = service.Insert(postUri, entry);
Tip: Use Calendar API calls in a batch when possible to increase performance.

Using Documentation and Help Forums

Google provides very good documentation that can be accessed here. Marketplace listing and installation are very simple and instructions can be found on the Google Marketplace site. If you don't find what you need in the documentation, the first place to look is the Google Apps Discussion Groups. We were able to find everything we needed to build and integrate ScheduleOnce with Google Apps. The APIs and documentation made the job easy.

Check out ScheduleOnce at www.scheduleonce.com

Users of cloud-based business applications shouldn’t have to create, remember and maintain new credentials for each of the many apps that they use. With applications on the Google Apps Marketplace, they don’t need to-- these applications allow users to login with their existing Google Apps accounts using OpenID.

We chose to power our Single Sign On (SSO) using OpenID because it’s the predominant open standard for federated identity on the web. The protocol is supported by a large number of OpenID identity providers and many sites around the web accept it. And to make Single Sign On easy to access, Marketplace apps also plug in to both the universal navigation bar inside Gmail, Calendar, Docs, and Sites, as well as the administrative control panel.

To enable the Single Sign On experience for Marketplace apps, developers simply need to add a universal navigation link and an OpenID realm to their application manifest. Adding these elements is easy-- it’s just a snippet of XML:

<Extension id="navLink" type="link">
<Name>Amazing Cloud App</Name>
<Url>http://www.example.com/home.php?domain=${DOMAIN_NAME}</Url>
</Extension>

<Extension id="realm" type="openIdRealm">
<Url>http://www.example.com</Url>
</Extension>

With this XML in the application manifest, a link called “Amazing Cloud App” will appear in the universal navigation of all Google Apps. Also, if one of the realms specified in the manifest file precisely matches the openid.realm in the OpenID request, then the user will be seamlessly signed into the app after clicking on the link in the universal navigation (without seeing a typical OpenID interstitial allow/deny page).

Of course, you’ll also need code in your application which accepts OpenID logins. In addition to open source libraries, here are a few companies that are making it easier for cloud applications to integrate with the Google Apps Marketplace. Their code provides simple APIs with which developers can integrate, leaving some of the complexities of the OpenID protocol to be implemented by the experts -- no need to hand-roll your own OpenID code.

  • JanRain
    JanRain’s open source PHP and Ruby OpenID libraries and on-demand RPX solution enabled the implemention of OpenID for many of the companies that launched on the Google Apps Marketplace by writing simple code or web service calls.
  • Ping Identity
    Ping’s PingFederate is an on-premise service that allows SaaS applications to easily accept OpenID and SAML-based logins by integrating with their libraries or using their web server or application server plug-ins.
  • TriCipher
    TriCipher’s myOneLogin Identity Services is an on-demand application that allows developers to accept OpenID, SAML and other federation protocols by writing simple web service calls.

Their are plenty of open source OpenID libraries available for other platforms, such as OpenID4Java (using Step2 code for Google Apps) and DotNetOpenAuth. More information on implementing Single Sign On in Google Apps Marketplace apps can be found on code.google.com.

If you need additional information on building apps for the Google Apps Marketplace, see the Developer’s Overivew on code.google.com.