Access control has two components, referred to collectively as auth.
Third-party applications often require limited access to a user’s Google Account… all requests for access must be approved by the account holder.
Authentication refers to the process of allowing users to sign in to websites. In the context of this blog, it also refers to sign in to applications using a Google Account, or an OpenID 2.0 based protocol. When Google authenticates a user’s account, it returns a user ID to the web application. This allows user information to be stored and collected. Open ID also allows access to certain user account information, with the user’s approval.
Authorization is often confused (by me, maybe others) with authentication. Authorization lets a user authorize access by applications to specific data associated with the user’s Google account.
OAuth 2.0 Protocol
The OAuth 2.0 open-standard protocol allows users to authorize access to their data, after successful authentication. Google supports the OAuth 2.0 protocol with bearer tokens for web (and installed) applications. Regular Google account data and Google Apps account data are accessible with OAuth 2.0. OAuth 2.0 relies on SSL for security instead of direct cryptographic signing that would otherwise be necessary for such access.
Note that OAuth 2.0 has not been finalized, according to IETF (version 13). Google cautions that it’s OAuth 2.0 support is in an early preview and may change at any time, or as the final specifications evolve. Google considers OAuth experimental. However, “experimental” does not have the same tentative connotation associated with Google Labs projects.
OAuth 1.0 Protocol
There is also an OAuth 1.0 for web applications. OAuth 1.0 can be used for authorization to user data by all Google API’s. Google continues to support OAuth 1.0.*
* OAuth 1.0 is sometimes referred to in documentation without version number, only as OAuth.
The OpenID-OAuth hybrid protocol provides authentication and authorization in a single-step process. Open ID provides authentication services, and OAuth provides authorization to Google APIs.
AuthSub API is Google’s proprietary protocol. It is mostly used for Google APIs. AuthSub is similar to OAuth. OAuth is more generally applicable and Google recommends that developers use OAuth instead of AuthSub API.
Registering a web application is optional. It is also free and straightforward. Web applications that are not registered with Google can still use OAuth 1.0 or AuthSub interfaces. However, registered web applications are recognized by Google and receive a correspondingly higher level of trust designation. This is communicated to users on the login screen.
Sample Google access request screen for unregistered web application
These are the three levels of registration:
- Unregistered These applications conduct transactions at a lower security level. Google flags the user login page with a precautionary message. See image above with yellow-shaded advisory.
- Registered and recognized but not configured for secure requests
- Registered with enhanced security These applications have a security certificate and can use secure tokens.