Best practices for the OAuth "application server" - Square

Question

I have an application that uses personal access token to access to GET the list of items. I want to switch to using OAuth, the application will use ITEMS_READ only.

My application is a daemon running on an instance of secure Ubuntu server dedicated to this application(s). Regarding the "application server" is there anything that square recommends - what are typical best practices with the "application server"?

Thank you

Answer 1

The API documentation is fairly extensive, and includes a helpful section about OAuth. A few common pitfalls I've noticed with OAuth implementations in the past lead me to call these things out:

1. If you are only building a one-off integration for your own use, it is probably not worth using OAuth.
2. Make sure you understand how OAuth works. If you find yourself asking for users' client secrets or personal access tokens, or anything else that requires them to open the app management dashboard at connect.squareup.com, you need to rethink your implementation. Only you, the developer, should need to understand access tokens and other API credentials.
3. You can generally ask for more OAuth scopes than the bare minimum that you need. I'd recommend getting MERCHANT_PROFILE_READ as well. That can be useful to manage accounts, and so you can hit /v1/me to get various IDs you'll need.
4. The Square OAuth access tokens expire as described here. They last for thirty days, so this can tend to creep up on developers who aren't aware of it. You will need to use a scheduled task to renew access tokens that are about to expire and purge your old tokens after doing so. Something as simple as a cronjob should be fine.

In terms of the technology stack you use, that's entirely up to you. The Square Connect team is happy to help and provide recommendations when we can.