Skip to main content
Skip to navigation

Add authentication to your mobile app

Turn on authentication in the RevenueCat iOS or Android SDK and send the ID token from your identity provider after each sign-in

Ask RicoChatGPTClaude

This article shows you how to add authentication to your iOS or Android app. You'll turn on authentication in the RevenueCat SDK, listen for authentication events, and send the ID token from your identity provider to RevenueCat after each sign-in. By the end, RevenueCat will identify each Customer from a verified ID token, and your app will hold a RevenueCat access token for that Customer.

📘Private beta

Authentication is in private beta, and its API can change before the general release. Tell us about your use case to get early access, and talk to your RevenueCat contact before you use it in a production app.

Migrate an existing app with a coding agent​

If your app already uses the RevenueCat SDK, you can have a coding agent, such as Claude Code or Cursor, do this migration for you. Copy the prompt below into your agent, with the RevenueCat MCP server connected to your project.

The agent works in two parts. First, it reads your code and your RevenueCat project without changing anything, and shows you one migration plan. It covers the identity provider, the SDK upgrade, how existing Customers keep their purchases, and the migration mode. After you approve the plan, the agent upgrades the SDK, creates the authentication methods, updates your sign-in code, and builds the app on a new branch. It stops and tells you when something blocks the migration, such as an identity provider that RevenueCat doesn't support yet.

⚠️The agent writes to your RevenueCat project

The agent creates authentication methods and can change the migration mode, which can stop older app versions from working. Use a key with only the scopes that it needs, as the MCP best practices describe, and never paste a secret key or a token into the chat. The agent asks you before it chooses a stricter mode. The Dual mode doesn't stop requests that use the public API key, so it doesn't yet protect against someone who acts as another App User ID.

Review the plan and the resulting changes before you merge them. The agent can't finish a real sign-in in a simulator, so test each identity provider with a test account yourself.

Prerequisites​

  • An authentication method in your RevenueCat project for the identity provider that your app uses
  • The RevenueCat iOS SDK version 5.88.0 or later, installed in your app, or the RevenueCat Android SDK version 10.29.0 or later, installed in your app
  • Sign-in with your identity provider working in your app, so that your app can get an ID token
  • Read Authentication for how the identity provider, the method, and the access token fit together

1. Turn on authentication in the SDK​

On iOS, import the SDK with @_spi(Internal), then set iamEnabled to true when you configure the SDK. On Android, opt in to InternalRevenueCatAPI, then call iamEnabled(true) on the configuration builder. Every authentication API on Android needs this opt-in.

// Authentication is behind an internal flag during the beta
@_spi(Internal) import RevenueCat

let configuration = Configuration.Builder(withAPIKey: revenueCatAPIKey)
.with(iamEnabled: true)

Purchases.configure(with: configuration.build())

On iOS, if your app uses RevenueCat from app extensions, such as widgets, configure the SDK with .with(iamEnabled: true, keychainAccessGroup: "<YOUR_KEYCHAIN_ACCESS_GROUP>") instead. The SDK stores the session in that keychain access group, so your app and its extensions share the same Customer.

When the SDK initializes, it creates an anonymous Customer and starts a session for that Customer. Each sign-in that follows attaches an identity to the Customer. See Anonymous Customers and identities.

2. Listen for authentication events​

Set a delegate on Purchases.shared.authentication on iOS, or Purchases.sharedInstance.authentication on Android, to learn when the SDK updates the access token, and when refreshing it fails. Errors from an explicit login call go to that call instead of the delegate.

The SDK keeps only a weak reference to the delegate. Your app must keep a strong reference to it, or the delegate is released and stops receiving events.

Most apps don't need to read the access token, because the SDK sends it with each of its own requests. Read it when your app calls your own backend, so that the backend can verify the token and identify the Customer. To read the current access token at any time, use currentAccessToken:

let accessToken = Purchases.shared.authentication.currentAccessToken

3. Send the ID token after each sign-in​

After your identity provider signs the Customer in, pass its ID token to logIn(using:) on iOS, or awaitLogIn(identity) on Android. On Android, logIn(identity, callback) is available for code that doesn't use coroutines. RevenueCat verifies the token against your authentication method and returns an access token. RevenueCat never receives the Customer's password, only the ID token.

Pick the tab for the provider of your authentication method.

This example is for iOS only. Apple returns the ID token as Data, so you can pass it to RevenueCat as it is.

4. Verify the sign-in​

Sign in to your app with a test account. The login call returns no error, and currentAccessToken returns an access token.

If an existing Customer already has the identity that you signed in with, RevenueCat merges the anonymous Customer into the existing one. The purchases of both Customers stay with the existing Customer.

Limitations​

  • Authentication needs iOS SDK version 5.88.0 or later, or Android SDK version 10.29.0 or later. The feature is behind an internal flag. Support for the hybrid SDKs will follow.
  • Apple ID sign-in is available on iOS only, and Google ID sign-in is available on Android only.
  • Your app must get an ID token from your identity provider before it can authenticate with RevenueCat. RevenueCat does not show a login screen in your app.

Next steps​

Was this page helpful?