Unacceptable audience in id_token: GoogleSignIn library

[ActuallyTaylor]

Bug report

Describe the bug

I have implemented the GoogleSignIn library for my application to retrieve data from the user's Gmail account. I would like to continue using the GoogleSignIn library in my app, but I also want to implement Supabase google authentication. Whenever I go to sign in the user using their idToken and accessToken I get the following error:

Unacceptable audience in id_token Auth.AuthError.api(Auth.AuthError.APIError(msg: nil, code: nil, error: Optional("invalid request"), errorDescription: Optional("Unacceptable audience in id_token"), weakPassword: nil))

I have checked my Supabase console and I am placing my iOS app's bundle ID into "Authorized Client IDs" which seems to only be for Android. Do I need to place this into the ClientID? If so what would my secret be in this situation.

Additional context

I have the following code (condensed) which authenticates the user first with GoogleSignIn. It then takes the user object and takes the idToken as well accessToken and provides them to Supabase's signInWithIdToken function.

let result = try await GIDSignIn.sharedInstance.signIn(withPresenting: window, hint: nil)
        
let user = result.user

guard let idToken = user.idToken?.tokenString else {
	return
}

try await supabase.auth.signInWithIdToken(
    credentials: .init(
        provider: .google,
        idToken: idToken,
        accessToken: user.accessToken.tokenString
    )
)

[grdsdev]

Hi @ActuallyTaylor we have a new guide for Google Sign-In, can you check it?

[dshukertjr]

@ActuallyTaylor The error most likely means that you didn't set the web client ID in your Supabase dashboard. Google uses web client ID to verify the token instead of the iOS client ID, so although you do need to create the iOS client ID as well, you do need to create the web client ID in addition to it, add it your application and add it to the Supabase dashboard.

[Objy-marcus]

I believe I have the same issue here, and the core of it is in this sentence from OP: I would like to continue using the GoogleSignIn library in my app, but I also want to implement Supabase google authentication

Using the example from @grdsdev with GoogleSignIn works well, you need to make sure your swift project or GoogleSignIn configuration is using an iOS OAuth 2.0 Client IDs from your Google Cloud console. I am following that example and it's code and it works.

One point to add is that when using GoogleSignIn I have found I need to put the iOS OAuth 2.0 Client IDs from your Google Cloud console into the Client ID (for OAuth) on the Supabase Dashboard > Authentication > Providers. Is this expected?

The issue is if for some reason you also want to use the following:
let session = try await supabase.auth.signInWithOAuth( provider: .google )

try await supabase.auth.linkIdentity(provider: .google)

To use the above two code snipped you need to use an OAuth 2.0 Client IDs from your Google Cloud console that is not an iOS client

This is where the conflict arises.

Using the example linked for GoogleSignIn with a non iOS Client in the Supabase Dashboard > Authentication > Providers results in the following error:
https://supabase.com/docs/guides/auth/social-login/auth-google?queryGroups=platform&platform=swift

Google 400 Error: invalid request Custom scheme URIs are not allowed for 'Web' client type

But if you update the OAuth client ID and secret on Supabase Dashboard > Authentication > Providers to be a web OAuth client then your GoogleSignIn returns the error:
Unacceptable audience in id_token

If you use a non iOS Client in the Supabase Dashboard > Authentication > Providers you can make the signInWithOAuth and linkIdentity methods work successfully.

If you have an iOS Client in Supabase Dashboard > Authentication > Providers and try to use linkIdentity (my particular use case) you get the error:
Error 400: redirect_uri_mismatch

I believe this is because there is an incompatability with iOS Client and Web Client which is what linkIdentity is trying to call if you inspect the url resultant from linkIdentity.

I hope this makes sense, happy to expand on any of the above.

To help understand why it is important, when using Anonymous users there seems to be no way besides using the above conflicting method to create and link an account if the user has registered anonymously.