Skip to main content
Skip to navigation

Verify access tokens on your backend

Use the RevenueCat access token to identify the Customer and protect the endpoints of your own backend

AIAsk AIChatGPTClaude

This article shows you how to use the RevenueCat access token to protect the calls between your app and your backend. By the end, your backend will reject requests without a valid access token and will know which Customer sent each request.

📘Private beta

Authentication is in private beta, and backend support is basic during the beta. Support for custom resource servers and scopes will follow. Tell us about your use case to get early access.

Prerequisites​

  • Authentication in your app, so that your app holds a RevenueCat access token for the Customer
  • Your app sends the access token to your backend with each request, for example in an Authorization header
  • Your RevenueCat Project ID, from Project Settings → General in the RevenueCat dashboard. See Project settings.

Choose how to verify the token​

The access token is a JSON Web Token (JWT) that RevenueCat signs with the keys of your project. Your backend can verify it in one of two ways.

ApproachUse it when
Verify the token on your backendYou want no runtime dependency on RevenueCat and the lowest latency. The token expires after three hours.
Call the RevenueCat APIYou also want the Customer's information from RevenueCat with each request.

Verify the token on your backend​

Verify the token with an established JWT library for your language. Don't write your own verification logic. A library handles the edge cases that cause security bugs. For a list of libraries, see jwt.io.

Check the claims and the signature​

Your backend must check four things before it trusts a token:

CheckClaimExpected value
Issuerisshttps://api.revenuecat.com/auth/{YOUR_PROJECT_ID}
Audienceaudhttps://api.revenuecat.com/auth/{YOUR_PROJECT_ID}
ExpirationexpA time later than the current time, in UTC
Signature—Signed by one of the public keys of your project

RevenueCat publishes the public keys of your project at its JWKS endpoint:

https://api.revenuecat.com/auth/{YOUR_PROJECT_ID}/.well-known/jwks.json

To verify the signature:

  1. Read the key ID from the kid header of the access token.
  2. Get the public keys of your project from the JWKS endpoint.
  3. Find the key with the same key ID. If no key matches, reject the token.
  4. Verify the signature with that key.

Cache the response from the JWKS endpoint, so that your backend doesn't fetch the keys for every request.

Read the Customer from the token​

After the token passes every check, read these two claims to identify the Customer:

ClaimValue
subThe RevenueCat Customer ID
rc.app_user_idThe App User ID of the Customer

Both claims identify the same Customer, but they hold different values.

Call the RevenueCat API​

Call GET /v1/customer with the access token in the Authorization header, using the Bearer scheme. The response contains the Customer Info of the Customer, and a user object that lists the identities the Customer signed in with.

GET /v1/customer HTTP/1.1
Host: api.revenuecat.com
Authorization: Bearer <ACCESS_TOKEN>
Accept: application/json

Replace <ACCESS_TOKEN> with the access token that your app sent. The access token is the only credential for this call. Don't send your public SDK key or your secret API key.

The endpoint reads the Customer from the access token, so the response is always for the Customer of that token. One access token gives access to one Customer.

Cache the response for 30 seconds. The cache saves latency on each request and reduces the load on RevenueCat.

Limitations​

  • The access token has no custom audiences or scopes during the beta. Every token for a project has the same issuer and audience.

Next steps​

Was this page helpful?