The two-factor auth system does not use the phone as a phone, just as a hardware token. Google displays a token on the login screen, you enter this in your phone and type the code it gives you in to the login page (similar to RSA's SecurID, but your phone is the device).
You seem to be referring to some othet Google auth system. The two-factor system used for Google accounts sends a code via SMS that you need to enter on the web page. It does not make you enter something on your phone.
Ah, I see. Yes, looks like Google offers multiple phone-based two-factor systems. I was referring to the oAuth one, which uses time-based tokens rather than sending the code via SMS.
I see. But does that qualify as a two-factor auth? You need two independent "factors" for that, and while OAuth uses tokens internally, all it does is ensure a secure transport between Google's servers and the app that requests authorization. It doesn't actually obtain two different things from the user.
No, that's not exactly what he means. The "token" isn't the OAuth native token, it's a 6-digit code that is based on the current time and a device secret embedded in the app on your phone.
What you are referring to isn't part of the OAuth spec, as far as I know, is it something particular to Google's API?
The cached access token could also be considered a factor, although it depends on the token expiry policy. If the token doesn't require a refresh using a refresh token (which must prompt a password) often enough its security is compromised.
I don't know what kind of expiry Google's OAuth token has, but last time I tested this, it was a very long time. I believe Twitter's live forever. Facebook's offline access scope (which you will need for a normal app) lives forever until the user changes his/her password (see http://developers.facebook.com/blog/post/2011/05/13/how-to--...).
There is an google authenticator app for android that you can register with your two factor auth so you can just open the app rather than wait for the text message.
