Google Adding Security Checks to Non-OAuth 2.0 Compliant Apps

Google announced it will add additional security checks to log-in attempts from applications or devices that do not support OAuth 2.0.

Google announced today that in the coming months it will be more stringent in securing users when they log in to their accounts by applying additional authorization checks.

“These additional checks will ensure that only the intended user has access to their account, whether through a browser, device or application,” said Antonio Fuentes, a product manager on the Google Identity Team. “These changes will affect any application that sends a username and/or password to Google.”

Google also appealed to developers to upgrade applications to OAuth 2.0, especially those that support plain passwords.

“If your application currently uses plain passwords to authenticate to Google, we strongly encourage you to minimize user disruption by switching to OAuth 2.0,” Fuentes said. “If you choose not to do so, your users will be required to take extra steps in order to keep accessing your applications.”

Google has supported the OAuth authentication mechanism since 2008. OAuth is an open standard for authorization that allows for secure token-based access to resources from a desktop, server or mobile device.

OAuth adoption has spiked in parallel with the use of Web services and cloud-based applications. Third parties that require access to a cloud application or resources can do so using an OAuth-supported client, which through the use of an access token can leverage those resources without the need for the resource owner’s credentials.

All of Google’s APIs work with OAuth 2.0, which supports integration with other IETF standards such as IMAP, SMTP, POP, XMPP, CalDAV, and CardDAV.

Meanwhile, an unrelated vulnerability in OAuth was patched yesterday. The vulnerability, reported less than a week ago, allowed an attacker could use an open redirect in the Twitter OAuth process to send users to a malicious page. The hacker would also obtain the victim’s OAuth token and verifier, the report said.

The fix involved ensuring that a certain parameter accept only hosts on white-listed domains as a mitigation.

Suggested articles