Is there a way that we can get all active oauth tokens for connected realm to application.
I need this as a fail safe. If e.g. user authenticates realm and we fail to save token and secret for realm, user is connected to our app, we are being charged but we cannot fetch any data so we need a service that will fetch currently active tokens and secrets.
Thank you
If you need to, you can go to the connections report in appcenter and disconnect the user manually. This will invalidate the tokens and they will need to re-authorize the connection.
Intuit does not provide any API that does this. Since providing an API like this would be a potential massive security hole, I wouldn't get your hopes up about this ever becoming available.
Have you looked into why your service is failing to save the token/secret/realm? That sounds like the place to start...
Related
I build an application that must use delegated AAD permissions to interact with the Graph API. App permissions are no option due to secruity restrictions.
This application is a background service which has some minimal UI for configuration of the application. The idea is to have users log into the UI once (via AAD), granting the required permissions. After that users will mostly never need to use this UI as there is nothing vital to configure.
This creates a situation where the user will only once present a usable access token. After that initial onboarding, the application will have to use a refresh token once in a while to keep being able to use the Graph API.
Is my assumption correct that in order for this to work, I must persist refresh tokens of each user? Intuitively this seems like both a security risk (if not implemented properly) and also a kind of complex system which would not only store tokens but also have additional background refreshing tokens and potentially informing users about eventual expired tokens (in case of failing token refreshs).
Yes, the refresh token you receive back is unique for each user, so you really need to keep the refresh and access token separate between each user and store them in a secure way.
Please also note that in some systems you get a new refresh token each time you use it.
Either you use the refresh token with a timer and refresh them each XX minutes. Or you do the refresh when the user receives a 401 Not Authenticated response from the API.
Can anyone provide a way to get the access token & refresh token without human interaction?
I've one account with which I have to make all the requests to quickbooks and don't want all my application users to provide quickbooks credentials.
It sounds like you're probably misunderstanding how OAuth works, specifically in the context of how Intuit wants it's customers to securely grant you access to QuickBooks data.
For each company who wants to connect your app to QuickBooks, you'll need human interaction to occur just once, and only once. This is not optional. It is mandatory. Human interaction is required one single time, and then after that you can exchange data with QuickBooks whenever you want, without any further interaction with a human.
Your application users will never provide QuickBooks credentials to you directly (e.g. you should not be collecting QuickBooks passwords or usernames).
Build your app to support OAuth2:
https://developer.intuit.com/app/developer/qbo/docs/develop/authentication-and-authorization/oauth-2.0
For each QuickBooks company (not each user, but each company) that you want to exchange data with, have one user auth via OAuth, just once.
You'll receive an access_token and a refresh_token. Save those in your database.
Once you save those, you never have to have a human interaction again for that connected company.
Use those tokens to make calls to QuickBooks. When the access token expires, use the refresh token to get a new access and refresh token. Save both new tokens to your database. Use those to make calls in the future. Repeat.
I have an app which requires users to log in. Logging in is handled via a POST request to my back-end REST API, which generates a new access token if the login details are correct and returns it to the app (which is then saved in the keychain). My question is, how do I handle cases when a user logs in from multiple devices at once? The device who logged in first will not realize that their access token has expired, but will continue to try to send requests which will be denied (because the access token no longer matches the one stored in the database). I have thought about checking that the access token matches the database token in viewDidLoad in my AppDelegate, but this would only work when the app is first loaded. Is there best practice already established for this sort of thing? If so what is it?
The best solution I have thought of so far is to just re-issue the same access token each time the user logs in, but this seems insecure to me. Is this a safe way to handle it?
It's a good practice to issue a new token on each sign-in. Tokens are meant to be expendable, and differentiating between user sessions on different devices and browsers is useful (see Facebook's session management for an example).
There are two possible ways to handle the double login scenario:
Maintain multiple active tokens for each user in your database and invalidate each on sign-out
Allow only one token per user, invalidating the existing token on sign-in
The choice depends on the nature of your application. In the second instance, the first client won't know that its session is invalid until the app makes a network call. At that time, your server should return a custom error to indicate that the token has expired. The app should then alert the user and return them to the sign-in screen.
I am trying to figure out how an access token in OAuth 2.0 should be used. To be more precise, I am trying to use the Google Plus API from a web application.
I am now able to get a code and from it an access token. The problem is that this token is only about 3600 seconds valid.
Is there a way to get another token without making the user go again through this process: https://developers.google.com/accounts/images/consent1.png because it seems a bit irritating. I know of the offline access and its refresh token, but it doesn't feel right to have permanent access to a user's account.
Do you have any ideas on how should I proceed?
I'm definitely not an authority, but I believe the answer is 'no'. The offline token allows you access without subsequent user approval, but only to the scopes to which the user already agreed when authenticating for the first time. Also, the user has the option of revoking your application's access at any time, which when combined with their previous consent means they both a.) know what they're allowing; and b.) can stop it at any time. Ostensibly, if a user uses your app enough that they constantly have to get a new token, they already trust it to act on their behalf within the scope you set, and the offline token is a way for you to take your relationship to the next level :)
I realize this is probably more philosophical than you were looking for, so apologies if it isn't pertinent to your situation.
Note: Although I raise this issue in the context of an iOS app, I don't think it's confined to an app running on that specific OS.
I'm developing an iOS application that will back up user data to a server and I'm trying to figure out the best way to verify server-side that the user being updated is actually the real user. Each user will have an id (uid). If that's all I depended on server-side, then I imagine the process would go like this:
User runs app for the first time
Creates account in the app, which communicates with the server to both create the account on the server and to get a unique "user id" (uid)
App stores this uid so that it can identify the user in subsequent communications with the server
However, if someone were to hack the app on their iphone, they could change the user id value and then that would instantly give them access to/allow them to modify a different user's data.
The current solution I'm considering is that the user receives 2 unique ids, the uid (just an auto-incremented number) and a longer, more complex key string. All communication with the server will therefore have to send along both the uid and the key. The server will verify that they match in order to make sure that the user truly is who the app says it is.
So, my question is two-fold:
Is this the correct way to achieve this? Or is there some other standard method that I should pursue?
If this is the correct approach, what's the recommended way to generate the unique key?
First of all, you can use the more complex value as the user ID to begin with, if you like (e.g. a UUID). Monotonically increasing IDs get hard to manage as your service scales.
You have the same problem a secure web site does when it leaves secure cookies on the browser to remember a session. Those cookies do include the user ID, but must prevent tampering. This is generally done by signing the cookie on the server before sending it back.
So what you'd do is:
Generate the user ID on the server, and use it to create some sort of "auth token" for the client to have to sign in.
Sign the auth token on the server with a secret key that only your server knows.
Send the auth token to the client, where it is stored for all subsequent logins. Transfer the auth token over HTTPS to prevent someone else from snooping it on the network.
When the app goes to login, send up the auth token to the server. If it's been hacked, the signature validation will fail, and you'll know to reject the client.
Consider including a timestamp in the signed token as well, so it expires after some time, forcing the server to regenerate an auth token periodically, which protects you in case your key is compromised. It's hard to do this all fully unless the user himself has a shared secret/password he can use to authenticate periodically as well. Depends on how far you need to go.
Other considerations: If all you know about a user is their generated UID, you don't have any way for that user to come back later from a different iOS device and restore their account there, right? Generally, if the user will be creating anything "valuable" in their account that they'll want access to later, you'll probably want to create a more traditional user account backed by an email address and password or the like, so they can access the account again after reinstalling your app. (This may or may not be relevant to your case.)
I would recommend going the "standard web browser way" and just letting the user set an email (login) and password.
When the iOS device connects to the server (using HTTPS), it uses regular "basic authentication" to log in, and receives a cookie which is valid for a set period of time. As long as the device keeps requesting data from the server within the cookie's lifetime, the cookie is renewed, and when the cookie is expired the server will automatically challenge the client to log in using its stored information again.
This has some advantages;
The user can log back into his account with a new device with a regular password reset. Easy, straight forward solved problem.
There is no special solution on the server side, any server side script can require authentication just like it would for a browser - built in functionality.
You would not have to invent your own security scheme. This scheme is used by millions of browsers every day to authenticate to web sites.
Not tied to a special phone, if the user has several iOS devices, he can use the same account from all of them by just logging in. No special set up procedures.
In other words; no special solutions for you to develop, generally solved problems how to handle login information, proven security and ease of use.
According to me, you can't really beat that :)