Clarification on OAuth flow for Mobile Payments SDK

Questions
,
1

Hello,

I’m a bit confused about the intended OAuth flow for the Mobile Payments SDK.

In the migration guide it looks like each store (location) should authorize directly inside the mobile app. However, the documentation also says that Square recommends tracking expires_at on the server and refreshing tokens before they expire - which suggests that the main authorization flow should happen once on the backend, and the mobile app should only receive a valid access token:

Square recommends tracking the expires_at value on your server and refreshing the authorization token before it expires. You can store expiration time on the device and check it during application initialization.

Could you please clarify the correct approach for production apps? Is the recommended approach that every mobile app instance should perform OAuth authorization itself, or is it better to authorize once via a web flow (on our server), store and refresh the token server-side, and then provide the mobile app with a valid access token?

2

:waving_hand: I’m Square Dev AI, here to help answer your question!
Based on the information you’ve provided, the following documentation will help answer your question:

Additional Documentation

OAuth API
OAuth API
Authorize the Mobile Payments SDK

If this documentation helped you find a solution, please check the box indicating that this reply solves the problem.
Otherwise one of our Developer Advocates will provide additional assistance shortly.

3

There is two levels of authorizations here. The first is OAuth, and if your app is for many sellers to use then they have to OAuth to your application and you get an access token that needs to be refreshed on a regular cadence.

The second is with the AuthorizationManager which handles authorizing and deauthorizing your application to process payments on behalf of a Square seller using an OAuth access token and a location ID within the app. :slight_smile:

4

Thanks for the response!

Just to clarify — I understand the difference between:

  1. OAuth authorization (merchant logs in, app gets access_token + refresh_token)

  2. AuthorizationManager inside the Mobile Payments SDK (authorizing the SDK using an already obtained OAuth access token + location ID)

My question is specifically about OAuth, not AuthorizationManager.

According to the documentation for Mobile Payments SDK, Square recommends keeping track of expires_at on the server and refreshing the OAuth token before it expires. This suggests that the recommended production architecture is:

OAuth → done once on the backend (server-side),

Server stores and refreshes OAuth tokens,

Mobile app only receives a short-lived access token to pass into AuthorizationManager.

Could you please confirm whether this is the recommended approach for production apps?

  • Should OAuth happen on the server, and the mobile app should only receive a valid short-lived access token?

Or:

  • Is Square expecting that each mobile app instance should perform the full OAuth flow itself using PKCE?

I want to make sure our architecture matches Square’s intended production use.

5

OAuth should alway happen on the server side and all values returned should be stored on the server side.

The server only passes the access token when calling the AuthorizationManager to authorize the app and the access token should NOT be stored on the app itself. :slight_smile: