Working together to improve user security

FEB 05, 2019

Posted by Adam Dawes

We're always looking for ways to improve user security both on Google and on your applications. That's why we've long invested in Google Sign In, so that users can extend all the security protections of their Google Account to your app.

Historically, there has been a critical shortcoming of all single sign in solutions. In the rare case that a user's Google Account falls prey to an attacker, the attacker can also gain and maintain access to your app via Google Sign In. That's why we're super excited to open a new feature of Google Sign In, Cross Account Protection (CAP), to developers.

CAP is a simple protocol that enables two apps to send and receive security notifications about a common user. It supports a standardized set of events including: account hijacked, account disabled, when Google terminates all the user's sessions, and when we lock an account to force the user to change their password. We also have a signal if we detect that an account could be causing abuse on your system.

CAP is built on several newly created Internet Standards, Risk and Incident Sharing and Coordination (RISC) and Security Events, that we developed with the community at the OpenID Foundation and IETF. This means that you should only have to build one implementation to be able to receive signals from multiple identity providers.

Google is now ready to send security events to your app for any user who has previously logged in using Google Sign In. If you've already integrated Google Sign In into your service, you can start receiving signals in just three easy steps:

Enable the RISC API and create a Service Account on the project/s where you set up Google Sign In. If you have clients set up in different projects for your web, Android and iOS apps, you'll have to repeat this for each project.
Build a RISC Receiver. This means opening a REST API on your service where Google will be able to POST security event tokens. When you receive these events, you'll need to validate they come from Google and then act on them. This may mean terminating your user's existing sessions, disabling the account, finding an alternate login mechanism or looking for other suspicious activity with the user's account.
Use the Service Account to configure Google's pubsub with the location of your API. You should then start receiving signals, and you can start testing and then roll out this important new protection.

If you already use Google Sign In, please get started by checking out our developer docs. If you don't use Google Sign In, CAP is another great reason to do so to improve the security of your users. Developers using Firebase Authentication or Google Cloud Identity for Customers & Partners have CAP configured automatically - there's nothing you need to do. You can also post questions on Stack Overflow with the #SecEvents tag.