We use XERO to authenticate and sign in to our app on firebase, however, we dont want a user to connect with multiple organisations, we just want a user to sign in and choose a single organisation.
If we remove all tenant connections from our app once a user have finished signing in, this will solve our problem, and we already do this upon logout for the same reason.
I just wanted to find out, is there any implications of doing this ? Will our logged in user still be able to make api calls and get new access tokens ?
I could not find any info of this in the XERO docs.
Thanks
The list of connected tenants represents the orgs the user has authorized your app to interact with their Xero data on their behalf. Deleting the connections by making a DELETE call to the connections endpoint with a specified connection ID will effectively un-authorize your app to interact with that orgs Xero data until the user reauthorizes your app to do so.
So, the shorter answer is - no, you won't be able to make api calls after disconnecting.
What I think you are after is limiting the XeroAPI access_token to only be able to write to a single org at a time. This can be achieved through your UX by simply deleting all connections if they try to go through your authorize flow a second time.
That way you are limiting their API connection to a single org, and if they want to change the org they are connecting to they can use your UI to disconnect/reconnect to another one.
XeroAPI Documentation
https://developer.xero.com/documentation/oauth2/auth-flow
Removing connections
If you would like to remove an individual tenant connection from your app (e.g. a user wants to disconnect one of their orgs) you can make a DELETE request on the Connections endpoint:
DELETE https://api.xero.com/connections/{connectionId}
Related
I want to build web app that uses Spotify API. I got case where user has to authenticate with his spotify account, then I recive access and refresh token that is being used in code to authenticate calls to Spotify to perform some actions on user's account.
I have trouble deciding how it should be really done. First thing that came to my mind - store them in Redis for some time, update on refresh and whenever we need to perform some action on any user we get his credentials and do it. Is this proper way? I tough about simply storing them in app memory but I might want to make in serverless.
Did anyone come accross that kind of problem? Do anyone know how to do it 'properly'.
For the past few years I have been using an unattended remote server to process invoices through the XERO API (Oauth 1.0)
Periodically (every financial year) we create a new XERO organisation to keep things tidy and avoid slow down.
I have just come to create a new organisation and associated app but have found that I can only use Oauth 2.0, which I do not have a massive issue with, BUT the fact I have to 'user' authenticate is going to be a real problem as my process is 'unattended' and started via CRON jobs.
Can anyone tell me if there is a way around this? and if not are there any solutions to do this?
Alternatively is there any way I can change one of my existing Oauth 1.0 apps to point to a different organisation (i.e. the new one I have just created)?
It seems a little short sighted not to have considered unattended processes, I cannot be the only person doing this??
Any help or pointers would be greatly appreciated.
Thanks,
Mike.
Yes you are not the only one doing this :) & yes, private apps are essentially deprecated end of 2020 - the move was not taken lightly. Since every API action through Xero's api is on behalf of a user account the team decided to move towards OAuth2.0 (Industry Standard) with a user consent screen.
If you need these long standing api connections on behalf of a user - they will need to initially authenticate that API connection at least a single time to get you an access_token and `refresh_tokenà . Access tokens are valid for 30 minutes, while the refresh token is good for 60 days.. So as long as you refresh > 2 months you can persist that longtail process.
If you don't have the means to build out that initial authentication screen to have your user validate on their own, you can use this CLI tool to get your initial token set to securely store in your remote server. An additional change is that that (or some) process will need to ensure the token is refreshed before use, and has given permissions to connect to a specific user's tenant-id as they might be a part of multiple Xero orgs & that manual consent screen is where a user selects which tenant/org they are giving API permissions to.
CLI to get Xero tokens from the command line
https://github.com/XeroAPI/xoauth
More info here: https://community.xero.com/developer/discussion/109207632#answer110970761
UPDATE
client_credentials aka machine to machine are coming to Xero's OAuth2.0 gateway.
You can read more about it here:
https://developer.xero.com/announcements/custom-integrations-are-coming/
I am trying to come up with something which will be scheduled to run daily and would import newly created invoices from a database into Xero. To have this run daily, I want to avoid logging in manually i.e entering username and password for logging into Xero, is this possible?
So if you are reading and writing data to a Xero org on a customer's behalf, they will need to authenticate that connection a single time. From there you can use OAuth 2.0 access_tokens & refresh_tokens to programmatically run scripts that connect to their org via Xero API. We are looking at ways to make this easier while maintaining security standards for use cases like this. But for now you will need to prompt a user login and save the credentials in your database/store.
A daily update can be performed without user interaction, but does need the user to authorise your application the first time.
After that, your application can use the 'refresh token' to automatically generate a new access token each day.
2 important things to remember:
you need to specify 'offline_access' in the SCOPE to give you the refresh tokens in the response.
save the refresh token to a db or file, and then use this each day to obtain new set of tokens (without user interaction). When new tokens are obtained, use access token to perform your updates, and save refresh token for tomorrow.
I'm trying to create a website to authenticate users through the use of a throwaway password where the assumption is that the user might not use the website again (basically a one time access).
I have done my research on OTP and various solutions to authentication but these don't seem to fit my requirements, most of them seem to rely on users having login credentials to the website whereas my system would allow them access without the need for registering.
The implementation of passwordless authentication by Auth0 seems to fit what you're describing. Even if you were not considering a third-party provider it may be useful to go through the documentation.
Basically, a user can login to a site without any need for a sign-up process. They can do so just by requesting that a one time code is delivered to them, for example, either by email or SMS.
This way, they can get quick access without having to setup a user and in the event that they do come back your application can recognize this because they will most likely be using the same mechanism, that is, you can use the email or mobile phone as the unique identifier.
Disclosure: I'm an Auth0 engineer.
If you do not require your users to register, why do you need authentication at all?
Why not just set a cookie with an unique identifier on the first visit? You can store data at the server side associated with that identifier. Keep track of when you last saw the user, and if they do not return within a certain period, you can delete any data you stored for that user.
If I'm using JWT to authenticate users to get access to my API, would it be possible to create one "generic" account for many users to use? That way, users who don't have a "real" account, would be given this generic account credentials in order to access the API. Would that be possible? Because, I'm wondering, with JWT, if one users log in, would I invalidate the other user token?
If that approach would not work, what would you recommend?
The reason: I want my app to communicate with my server, even if the user doesn't have an account created. But I would not like to keep that "door" open, hence I would like to add some kind of authentication for those people who are using the app but don't have an account. Suggestions?
Create accounts connected with accountgroups. This way you are also able to create temporary accounts having less permissions for example. And multiple clients are able to access same data and same time.
So the Payload is owned by the accountgroup, the client authenticates with a (maybe temporary) account and gets authorization via accountgroup.