Integrating Google Sign-In for Web Applications, the Security Considerations
Google Sign-In is one of the most popular third-party login methods. Google Sign-In is my personally favorite Sign-In method as a security-conscious user. Google invested heavily into security of their identity platform, implementing features including adaptive 2FA, detection of anomalous activities etc. Google never recycles Gmail addresses. It’s safer than using your own domain, which may expire after a person fails to renew it (for example, domain owner passes away).
Compared to other social login methods, Google Sign-In has clear advantages:
Facebook Login. Facebook is usually not accepted by SaaS software. I am also concerned about friend list exports. Maybe you are not granting the permission, but your friend may give the 3rd party site about the connection.
Sign in with Apple. Limited adoption and web experience.
Sign in with Twitter, Sign In with LinkedIn, Login with Amazon, etc. Limited adoption.
In addition, Google Sign-In provides a superior sign-up and login experience, reduces friction and potentially increases conversion. In many cases, either for SaaS applications or consumer-facing applications, implementing Google Sign-In would be a good idea for your business.
The following content describes common security considerations we came across when integrating Google Sign-In.
Gmail Address Normalization
An open secret about Gmail accounts is that each account has many aliases. For example, the following email addresses are considered the same account on Google:
If your web application has not already normalized Gmail addresses. It may be a good idea to normalize them before implementing Google Sign-In. It affects the way how existing email-identified accounts will be merged with the new login method.
Incorrect Interaction with Password Login
An attack scenario for account takeover could happen if the web application allows email-password sign up without email verification.
The victim isn’t a user of your web app. Attacker creates an account using the victim's email email@example.com, and a password. The account email confirmation isn't yet activated.
The victim firstname.lastname@example.org then signs up again using Google Sign-In. The victim put their information into the account.
The attacker may be able to log in using the password they created. The Attacker now may view the victim’s personal information.
There are a few possible ways to avoid the takeover vulnerability.
Disable password login once Google Sign-In is linked to the account.
Reset password once Google Sign-In is linked to the account.
Email confirmation completed cases: send a "security alert" telling the user that the existing account is linked with Google Sign-In.
Email confirmation incomplete cases: revoke existing password associated with the account, send a "security alert" to tell the user that their password is reset due to Sign-In. The user needs to go through the password reset flow if they want to use a password again.
Verification of Authentication Tokens
Google has provided guidance on verification of their “id token” returned by the sign-in process. However the backend server may have a faulty implementation that leads to security issues. Common cases of problem:
Lack of verification of client_id in token. Attacker uses a token from another phishing app they created.
Lack of verification of user_id (sub) in token. Your mobile/web app could pass a user_id alongside with the oauth2 token optimistically, but no verification of these two matching.
Lack of verification of the "email_verified" field. Not sure if this is really exploitable, but I hope the field should always be true.
Lack of checking expiration of the token.
To reduce potential mistakes, it’s recommended to use well-known verification libraries, especially those that are designed specifically for Google Sign-In.
Sign In With Apple Implementation May be Required
According to App Store Review Guidelines, if you have any social login method integrated, the app needs to offer “Sign in with Apple” to get app review passed on iOS. As the guideline text says:
Apps that use a third-party or social login service (such as Facebook Login, Google Sign-In, Sign in with Twitter, Sign In with LinkedIn, Login with Amazon, or WeChat Login) to set up or authenticate the user’s primary account with the app must also offer Sign in with Apple as an equivalent option.
This requirement adds to the complexity of integration. Especially with Apple’s Hide My Email functionality. Your application may need to consider situations where your application may not receive the users’ primary email addresses.