Best Practices for User Authentication
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
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.
By Jeffrey Posnick, Google Developer
Relations
