Working with the Google Data APIs - Authentication

[jeffgreco13]

I'm aiming to build an online application that interfaces with the Google Apps suite to allow for my clients to login and view basic data. I've been doing a lot of research on the various authentication methods but I'm still hazy on which ones I need and how to implement them (Google's own examples don't even work, or the examples require dependencies that arent included in the sources)

My application will ultimately accept a username and password for a user within the client domain (much like an intranet system). Once authenticated through Google's servers my application should now have access to this user's information across the various APIs Google offers. Freedom to make some minor changes, etc.

The problem is the authentication process. I believe my answer lies with OpenID + OAuth (because the administrator account can make global changes), but I am completely lost.

Does anyone have any hints or tips on how to work with OpenID + OAuth in Java?

[Tony]

If you are using Google's Authentication, then you application doesn't touch any usernames or passwords -- Google does. Google's servers then return a token saying "yeah, this user authenticated".

[jeffgreco13]

There's also a way to accept the username and password within your own application.

There's the auth token saying "yeah, this user's authenticated" then it needs to be sent back to have an access token returned and with THAT token I'd have access to the APIs.

What I'm wondering is if anyone has some experience with this?

[2goto1]

If you use open auth / open id, then you don't have to require passwords for your users. Think of it as an Single Sign On (SSO) security approach. Your visitors are already authenticated through their Google Account. And because Open Id / Open Auth are industry standard protocols, they're supported by hundreds of other websites, such as Yahoo, AOL, myopenid, etc.Each user that allows access to your site through their open id / open auth provider will have a unique user token sent to your website that you need to save in your membership database, that you can use to identify them in the future when they authenticate through their provider in the future.

On the Java side, there are libraries that have been created to make the process of working with Open Id easier, i.e. see http://code.google.com/p/openid4java/ as one example.

I've found that although you can request personal data from any Open Id / Open Auth provider, such as email address, name, location, etc. in practice you won't be sent that data all the time. When it is available though it can simplify your user's registration process on your website since they don't have to enter that stuff manually on your site.

[jeffgreco13]

What do you think of this kind of "hacked" method:

Considering I will be installing a separate edition of this software on each client's server account, only users with the @clientdomain.tld address will be able to access the program at the given address (http://admin.clientdomain.tld).

Request username and password from withing MY application. ie) username = "jeff" when email address = "jeff@clientdomain.tld".
My software will detect if the entered username is an email address or not. If it isn't it will append the @clientdomain.tld.
Send a request to Google's ClientLogin using a PHP http_request. If the returned value is an Auth token then grant access, if not then deny.
Once authenticated through the server my application will store the email address in a session variable and the various features/APIs will use 2-legged oauth to receive the user data.

In theory this sounds like it could work. Considering the only users that will be allowed to use this software will be those within the domain (Intranet) there isn't much of a reason to explain to them why they should trust the software/grant access to it.

Keep in mind my program will be running under a SSL of course.

[2goto1]

Sounds like it should work. For an intranet I usually would avoid dependencies on 3rd party systems for user accounts, but it should work.

Many enterprises have active directory / ldap user databases that you can already authenticate against, for intranets I normally take that approach. For those that don't they may still have their own corporate email addresses, which I would normally base logins on as an alternative. But regardless, the idea that you have should work fine.