We’re a POS system integrating Square terminal. Our system is distributed client/server, NOT cloud-based. Reading through the OAuth docs, the API seems to require a server to process and retrieve the authorization code to obtain a token… If every workstation would have its own IP address, I don’t see how I can put a redirect URL in our developer application profile that would resolve for all of them. Isn’t there a way to retrieve an authorization code without installing a webserver somewhere to parse the response? Why can’t Square simply display an authorization code for the user to copy into our program? Or an endpoint to query for an authorization code from a specific merchant ID?
Hi @Rick_Computerworks, welcome to the forums!
Not sure I’m understanding about the IP address situation - technically you will only have one OAuth redirect url for all your merchant clients. There is no way around this at this time unfortunately, and this is the only way to retrieve the authorization code (via a url parameter).
The issue isn’t the need for more than one redirect URL. The issue is that there isn’t a way to access/retrieve an authorization code from a desktop/laptop without a redirect URL and server somewhere. There should be an endpoint where the desktop app requesting an authorization code can perform a request authorization code after one has been issued without checking a redirect page to nowhere.
Got it, appreciate the feedback. I’ll update this to be a feature request for now, but it currently is not possible.
Given that you have a distributed client/server setup, why not just proxy this through one of the servers? The client could request an authorization token through one of your local servers. Ultimately, you need the bearer token to access the Square service from the client.
We install our system at our customers sites, but do not control or own their equipment, etc. So the customers would have to know enough about webservers and such, or we would have to support and maintain their webserver, which our tech support isn’t going to do, not to mention that some of our customers are colleges and universities that absolutely would object to us setting up a webserver… So things like utilizing the webhooks, or setting up a server that only handles the authorization redirect, are not practical.
We got around this issue by putting a generic page on our company’s website that simply responds to the redirect, and we grab the code from the redirect URL from an internal webbrowser window… At least we’re not sending our customers to a non-existent page, and we can make it look professional.
I’ve been intrigued with this issue and wanted to see what I could come up with. My solution is implemented using .NET Core 3.1. I’ve created a repo on Github with a working sample.
The console based application starts the authorization code request process by calling the Square authorization page through the local browser. The response from that page is returned to the console application in JSON format and displayed.
Technical Leverage
- OAuth redirect url can be pointed to localhost
- Kestrel (web server) is built into .NET Core
- Anonymous pipe for inter-process communication
I’m not sure if this is helpful for you but hope it’s helpful to others.
@Rick_Computerworks The solution you’ve implemented is currently our best recommendation.
My team at Square is advocating for the development of the PKCE OAuth extension. PKCE is designed to solve for the use case of public clients.
2 Likes
Out of curiosity, what is the rationale for the recommendation?In the absence of bespoke support for redirection to mobile/native apps as a feature of our platform and with the assumption that application secret is truly meant to be kept secret, any implementation which distributes an application secret to clients is considered a security risk. PKCE addresses vulnerabilities associated with public clients where clients can’t be trusted to keep the application secret confidential.
Square’s OAuth current Oauth implementation was built and designed for a server to server architecture and thus it doesn’t consider the implementation or security challenges of the public/non-server client.
For reference, Google segments Oauth implementations by type of client: server, JS client, mobile, and limited input. Google Oauth 2
Thanks for taking the time to respond. In the real world I would never do anything like this. All my access to Square APIs would be through a secure backend.
Given @Rick_Computerworks initial scenario of implementing an application calling Square APIs directly from a client, this was a possible technical solution. The idea of storing access tokens on the client is risky. I assumed he understood the risk, already had a risk mitigation plan and was looking for a technical solution for just getting the authorization code.
I’ll add caveats to the readme in the repository.
Thanks again for responding.