Skip to content

Google Sign In missing silent sign in #4750

Description

@Leinnan

Reason for the Feature

The Beamable.Platform.SDK.Auth.GoogleSignIn integration only supports the full interactive login flow. There is no way to obtain a fresh, up-to-date Google Sign-In token for an already-authenticated user without triggering the native login popup.

This causes problems for integrators who need a valid token to perform operations such as RemoveThirdPartyAssociation(AuthThirdParty.Google, ThirdPartyAuthToken). Google Sign-In tokens are short-lived, so any token cached (e.g. in PlayerPrefs) becomes stale and invalid over time. When a stale token is sent to Beamable, the internal request to the Google auth provider fails with a "Token not found" error.

The user impact is a poor UX: a player who wants to unlink (dissociate) their Google account must re-trigger the full login popup just to refresh the token — even though the intent is the opposite of logging in. There is currently no silent path to refresh the Google token.

Proposed Solution/Requirements

Add silent sign-in support to the GoogleSignIn package so integrators can retrieve an up-to-date Google token for a previously authenticated account without showing the interactive login UI.

Requirements:

  • Expose a silent sign-in method on Beamable.Platform.SDK.Auth.GoogleSignIn that returns a fresh token when the account was previously authenticated via Google Sign-In.
  • Back this with a silentSignIn implementation in the underlying Java class at plugins/google-signin/googlesignin/src/main/java/com/beamable/googlesignin/GoogleSignInActivity.java, which currently only supports the full login flow with the login popup.
  • No native login popup should be displayed during the silent flow.

Alternatives or Workarounds

  • Calling Login again to refresh the token — rejected because it displays the native login popup, which is a poor experience when the user's intent is to unlink/logout.
  • Storing the token in PlayerPrefs — unreliable, since these tokens are short-lived and become invalid over time (and storing auth tokens in PlayerPrefs is discouraged; if done, it should at least be encrypted).
  • Forking GoogleSignInActivity and adding a custom silentSignIn implementation on the integrator's side — this is the current recommended workaround, but it duplicates SDK code and puts maintenance burden on integrators.
  • Using GetCredentialStatus(AuthThirdParty.Google, token) to check whether a token is still associated with an account (CredentialUsageStatus.ASSIGNED_TO_AN_ACCOUNT) — useful for diagnosing association state but does not solve the token-refresh problem.

Additional Context

This surfaced from an integrator (using Beamable.Platform.SDK.Auth.GoogleSignIn) implementing associate/dissociate (link/unlink) of Google/Apple accounts, distinct from full account deletion. Note: a "Token not found" error on a repeated RemoveThirdPartyAssociation call for the same account is expected behavior — the first call already removed the association, so there is no token to find on the second call. The genuine failure case here is the stale-token scenario described above, which the silent sign-in feature would resolve.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions