You realise that providing this ability makes it very difficult to call it a secure application any more.
Implementing single sign on is a common way to do it within an organisation, but it requires an organisation-wide authentication framework that can be relied on. If you run Active Directory you can use it to provide auth tokens through its version of Kerberos, or under *nixes you can use real Kerberos.
Trying to use SSO to authenticate your users to a 3rd party requires a way to provide an auth token to the 3rd party. OpenID could work for your purposes here, but it will require either storing the token in the users' browsers, which will leave them open to attack if they leave their computer unlocked, or allowing your internal auth system to provide the OpenID to Google when the user tries to logon.
Not straightforward, and from a pure security perspective I would argue that it is a bad idea
Recommended practice is for the users to enter their username and password combination to at least provide you with some assurance that it is the user logging in, and not an attacker or someone else misusing their account.
For more information on the security aspects, have a look at some of the questions tagged with authentication over on Security SE.
Why don't you just use OAuth? This means until they log out of their google account they will be logged into your application. This is at least the case with Superuser for me. – Ramhound – 2013-02-05T11:56:13.140