feat: added OAuthService for social logins

[lwin-kyaw]

Description

Social login via OAuthController

Google
Apple

Social login authentication flow

This PR adds OAuthController to facilitate the social login in the metamask extension.
It does not include the Login UI Flow.

Related issues

Fixes:

Manual testing steps

1. Go to this page...

Screenshots/Recordings

Before

After

Pre-merge author checklist

• I’ve followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards.
• I've completed the PR template to the best of my ability
• I’ve included tests if applicable
• I’ve documented my code using JSDoc format if applicable
• I’ve applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.

[github-actions]

CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes.

[chaitanyapotti]

lgtm

[NicholasEllul]

When using the OAuth Authorization Code Flow, the typical pattern involves redirecting the user to a backend server that can securely handle the authorization code and exchange it for an access token. However, in our case, the authorization code is returned directly to the user’s browser. This presents a security risk, as the browser is a much less secure environment and is susceptible to interception by attackers, especially in MitM scenarios.

For client side applications such as desktop, mobile, or single-page web apps, this risk is commonly mitigated through the use of PKCE (Proof Key for Code Exchange). Okta has a nice intro on it here: https://developer.okta.com/docs/concepts/oauth-openid/#authorization-code-flow-with-pkce-flow.

Google makes PKCE mandatory for client side applications like mobile/desktop apps and IMO extensions fit into this category. Docs on this can be found here: https://developers.google.com/identity/protocols/oauth2/native-app#step1-code-verifier

Unfortunately, it looks like apple does not support PKCE, but getting this right for google would at least help us better secure accounts using sign in with Google.

Adding it here would look something like:

1. Generate the code_verifier and send the hashed version along with the authorization request to google
2. When we send our authorization code to the web3auth backend, also provide the code_verifier to included when exchanging the auth code for an access token
3. Google will validate the code matches the hashed version we had previously sent.

With PKCE in place, even if an attacker intercepts the authorization code, they would not be able to exchange it for an access token without also having the original code_verifier, which never leaves the client device.

[NicholasEllul]

I see this uses a chrome specific API. Do we have the checks in place to ensure this doesn't cause an error on firefox?

[NicholasEllul]

Will any of these create a new permission request popup for our users? If so please consult with @Gudahtt prior to merging this. In the past, it was determined that introducing new permissions prompts would drive users to uninstall the extension, and should be avoided unless absolutely necessary.

[NicholasEllul]

Similarly to the comment above, please confirm whether this will result in a new permission prompt for users.

[NicholasEllul]

To prevent CSRF attacks, OAuth2 strongly encourages that state is a unique & unguessable value. Redirect UI here will be something an attacker can predict, thus would be able to exploit.

These kinds of attacks work by having the attacker send a request to the chrome.identity.getRedirectURL() from their malicious site that contains an auth code associated with their own google login. The extension would then assume this was the auth code associated with the user who was logging in, and bind the attackers social login to their wallet. More on this can be read in this document under Flawed CSRF protection

Using a unique and unguessable value stops this kind of attack. That is because if the attacker did attempt to send a request to the chrome.identity.getRedirectURL(), they wouldn't know what the state value would be. As a result, the extension would reject any malicious requests of this kind.

[NicholasEllul]

We are missing the state parameter here. We should have it be a unique & unguessable value that we can later verify

[NicholasEllul]

A good value could be crypto.randomUUID()

[NicholasEllul]

Above I added a couple comments about the importance of the state value. In launchWebAuthFlow's optional callback we should validate that the state we get back from the oauth provider matches what we provided at the start of the flow. If the value does not match, we should throw an error.

[NicholasEllul]

A nonce should be cryptographically random to prevent replay attacks

[tuna1207]

@lwin-kyaw noble has this hash function support, i think we should try using that

import { sha256 } from '@noble/hashes/sha2';

e.g

#getHashedNonce(): string {
    const hashBytes = sha512(this.nonce);
    return remove0x(bytesToHex(hashBytes));
  }