Google OAuth flaw leaves many users vulnerable via failed startup domains

Google’s advertising practices are also subject to investigations or proceedings in Britain, the EU and the United States — © AFP/File Josh Edelson

A flaw in Google’s “Sign in with Google” authentication flow has the potential to expose millions of American users’ data, specifically those who have worked at failed startups. By purchasing failed startup domains, attackers can recreate former employees’ email accounts and access various SaaS platforms previously used by these startups.

According to Truffle Security: “Here’s the problem: Google’s OAuth login doesn’t protect against someone purchasing a failed startup’s domain and using it to re-create email accounts for former employees. And while you can’t access old email data, you can use those accounts to log into all the different SaaS products that the organization used.”

This vulnerability can have severe implications for unknowing victims, causing the potential leak of sensitive information including emails, passwords, addresses, and social security numbers.

Baber Amin, Chief Product Officer at Anetac has told Digital Journal what the primary risk considerations are: “OAuth usage can have unexpected consequences, especially for startups with limited security resources. To safeguard employees from potential threats, one must implement best practices in addition to the proposed technical controls to enhance the OAuth information flow.  Below are some suggestions.”

In terms of putting in place robust counter-measures, Amin recommends the following:

Regularly review and audit OAuth permissions. Access your data, verify the permissions granted, and revoke access for any apps that are no longer necessary. Additionally, limit permissions to the minimum required for each application to function effectively.

Enforce strict token validation. Ensure that your applications (and any third-party integrations) verify token signatures rather than relying solely on a domain name. Validate that the token’s aud (audience) claim aligns with the client IDs you expect. If the token contains an azp field, confirm that it corresponds to the authorized party.

Implement domain verification and SSO policies. Some providers allow domain ownership verification for SSO and domain-based claims. If you lose this verification (e.g., a domain is stolen), the provider can invalidate or remove the domain from your configuration to prevent unauthorized usage.

Integrate OAuth revocation into the offboarding process. Develop a clear offboarding checklist that includes token revocation as a formal step in the HR and IT offboarding process. When deprovisioning an employee, ensure that all third-party OAuth authorizations associated with their account are terminated. 

Centralized Identity Management: If you use a directory service like Google Workspace, automate the process of revoking access to third-party apps when an account is suspended or deleted.

Implement Routine Access Reviews: Schedule regular reviews of all third-party OAuth grants, typically quarterly or bi-annually. During these reviews, remove or renew only those grants that are explicitly needed.

Startup Shutdown Protocol: When a startup is shutting down, designate an owner to systematically revoke all OAuth grants for each user. Provide notice to third-party service providers that your organization’s access will be revoked and request confirmation that all tokens have been invalidated.

Automate via APIs or Admin Consoles:  Use the Admin console or APIs (such as the Directory API) to programmatically list and revoke OAuth grants for all employees.Documentation and Verification: After revoking access, perform a final verification step by ensuring that attempts to authenticate via any OAuth-secured application fail.”