Is this how we are doing Private Application from now on?

[mech]

Searching around Xero developer site, it is hard to know what to do if we have machine-to-machine integration going on using Private Application in the past.

It seems like we should use this xoauth approach. However, I am puzzled if my Docker Linux is using pure script, how does it have any browser to display in the OAuth flow?

Is Private Application and script-based use-cases totally impossible when Xero move to OAuth 2?

[SerKnight]

Hey Mech - yes this is a tool we've built to help folks to be able to achieve private app 'like' functionality within the functionality of our API. I recorded a tutorial on how to leverage this tool that might help de-mystify some of your confusion.

xoauth Tutorial

https://www.youtube.com/watch?v=Zcf_64yreVI

Because each API interaction in OAuth2 is on behalf of a user account, that user account will need to at least one time, authorize API access via browser. This tool makes it so you don't have to code & host an authorization page. It will enable you to authorize a user and receive back a valid tokenSet which you can then plug into your background process/script which will make API calls and programmatically refresh the initial tokenSet.

Refreshing access tokens

https://developer.xero.com/documentation/oauth2/auth-flow

[coxp]

Is there a good reason why you won't just add the client credentials grant type? We've been avoiding moving to OAuth 2.0 because frankly this is a horrible hack just to get machine to machine integration working.

[SerKnight]

Hi @coxp - It might be added in the future but not currently scoped.

If you need additional resources on how to code the refresh token flow you can create a case by emailing api@xero.com. Our team can help guide you through your specific situation.

[mech]

It is actually not hard to implement unattended machine to machine if you're willing to pay the up-front setup costs. You do need to have your script talk to a DB/filesystem of sort to retrieve back the access/refresh token though.

I am glad that I move to the new API which is so much more cleaner also.

[davefinster]

As a scenario, say one has a backend application that currently uses private app functionality to perform some background work with Xero. During deployment, someone uses the xoauth tool to dump an initial set of tokens and feeds them into the app. The app is correctly developed to leverage refresh token and renews as needed.

However, any real application is going to need some level of persistence of these tokens, so you store them in a database. That way, if you have multiple concurrent instances they can use the same credentials and you can use database transactions to avoid multiple instances trying to renew the credentials at the same time. Annoying to deal with, but it has obviously been decided that all private app developers need to do that.

How would one handle a situation where one of the instances goes to renew the token (since it currently holds a lock), it successfully makes the call to Xero to renew, but before it can write those new credentials out to anything the application or box crashes. At that point, the credentials in the database including the refresh token are invalid and the only entity with the new tokens lost them. All the instances are now wedged until...what? A human comes along to manually run the tool?

Or is it the case that the old access_token will continue to work until its expiry but the refresh token is invalidated? So it wouldn't be case that everything is immediately broken, but will be broken some time in the future (i.e. when access_token expires)

[iadaz]

Or is it the case that the old access_token will continue to work until its expiry but the refresh token is invalidated? So it wouldn't be case that everything is immediately broken, but will be broken some time in the future (i.e. when access_token expires)

If the token refresh is lost by a crash, you can refresh the old token for up to 30 minutes. https://community.xero.com/developer/discussion/105714701#answer118801141

[esb]

Let's face it. Xero have made minimal efforts to support this kind of use case. OAuth2 is great for 3rd party authentication on a browser app, but for machine to machine scripting it's a nightmare., Xero know this, but don't care. It's all in the name of security theatre.

In my view, using a pregenerated API key, together with IP address lockdowns is probably as safe as you can get. The added advantage is that it's simple and painless to implement, and works a treat. This is exactly the mechanism used by countless other products out there, even ones that need the same level of security for financial transactions.

[StevenMaude]

Off-topic for this repo, but others posting in or discovering this thread might find it useful. Particularly as no-one from Xero's staff thought to mention it. See the replies from 2020-11-16 onwards in this thread on their forum:

https://community.xero.com/developer/discussion/109207632

For those who didn't click: :tada: Xero finally conceded to adding a Client Credentials grant type for OAuth 2. … :upside_down_face: They're charging an as-yet unspecified monthly premium for it.

[mech]

Will give you a thumbs down for saying this is off topic. It is very much on point and thank you so much for the heads up 😀!