Quickbooks online API with oauth2 - php

I need to use Quickbooks online API to synchronize data between my system and my client's accounts on quickbooks.
I need to know if is it possible to complete the oauth2 authorization flow and make API calls without human interaction (without the need to interact with Intuit's authentication and authorization windows)?
I read the Intuit's docs on: https://developer.intuit.com/docs/0100_quickbooks_online/0100_essentials/000500_authentication_and_authorization/connect_from_within_your_app
On the first step, I made a GET request to:
https://appcenter.intuit.com/connect/oauth2?client_id=MY_ID&scope=com.intuit.quickbooks.accounting&redirect_uri=https%3A%2F%2FMY_NGROK_URL.ngrok.io%2FOAuth2PHPExample.php&response_type=code&state=RandomState#/Authorize/COMPANY_ID
Then, the Intuit's authentication and authorization windows opens and I need to put my username and password and then, click in the authorize button to get the authorization code.
Is there a way to obtain the authorization code without authenticate and authorize?
I need to automate this task to make API calls in the backend with PHP.
Thanks,
Marcelo.

Is there a way to obtain the authorization code without authenticate and authorize?
No... but read below.
I need to automate this task to make API calls in the backend with PHP.
You are misunderstanding how OAuth (either 1 or 2) works.
The very first time you connect you will be prompted to authenticate/authorize access to the QuickBooks Online data.
You are then given a refresh token (or access token depending on if you're using OAuth2 vs. OAuth1).
You then store that refresh token (or access token for OAuth1) and can use that token going forward to make your requests, unattended, without requiring the user to be involved at all.
Key take-away: You only need the user involved the VERY FIRST TIME you connect, and then never again.

Related

Central OAuth2.0 Authorization on the Backend-Side using PHP and curl for Spotify Web API

I am creating an application which aims at automatically creating Spotify Playlists in a central Spotify account (not the account of the end users).
I have set up this account and created the developer app for the secret and the client_id.
On the backend side, I am using PHP to authorize this central user, and it is working as long as I am logged in myself with that account.
Users that visit my website should be able to create playlists via that interface through the Spotify Web API without the need to authorize their account nor being logged in at all.
If I'm trying to open the same page on a separate device (without having any account logged in), it just gives me the following error:
User not registered in the Developer Dashboard
Is it somehow possible to perform this authorization process only on the backend side without the need for the user to authorize it?
Eventually, I want to send the playlist URL created in the central Spotify Account to the user who can open it in their own app or share with others, if they want to.
I try to avoid that multiple users must authorize for my app, since I don't need to access personal information from their account, anyways.
I used the 3-step process for authorization as described in this Stackoverflow Post: Spotify oauth2 with PHP curl. How to get authorization code?
If necessary, I will provide more information.
Do you have any idea, how I can implement this authorization process for the single account on the backend side, without the user even showing any authorization process of the Spotify Web API at all?
EDIT1: I am not trying to login on the behalf of my users, just automatically for my own account without the interactive login with Spotify. Is that even possible?
I received valuable feedback from the Spotify Developer Community that helped me finding a solution to the problem.
When you let the central Spotify account login to your app, you'll [get] an access_token (that will expire in 1 hour) and a refresh_token.
When the access_token of that account expires, let your server send a POST request to the Accounts service /api/token endpoint, but use the refresh_token in place of the access_token.
A new access_token will be returned.
A new refresh_token might be returned too. (I don't think that's even needed)
You can read more about it here.

Xero API authentication without OAuth2

The scenario
So I am building an app that should display data from my Xero account to the users. Users should not be able to login via OAuth2 to my web app so that's why I need persistent auth token that is independent from the users login. The current API authentication implementation from Xero does not allow that and the token expires in 30 minutes so I need a way to do this somehow in the background or with any kind of persistent token (which is not available as I can see in their docs for Auth)
Stack
I am using Laravel with the package Xero Laravel and this one's using the XeroPHP package in its core as dependency. Currently I am using Postman to do refresh token requests and I am adding the token manually (for testing purposes of course). This should not be the case when it goes on production, though. So I need a way to somehow "store" or refresh the token globally for the whole app and using only my account as an Authorization to Xero.
Problem summary
My web app need to fetch data (invoices data in particular) from my Xero account and no OAuth tokenization is required for the users (since I am using the native Laravel Auth for this purpos) that are going to read this data in a GUI.
How should I accomplish this without OAuth2 (if there is any way) or how I can do this if only my account is the "global" one for the app?
The other comments are correct that there is an initial required step to have the user that you are calling API endpoints on behalf of to authorize your API application.
Once you have their valid token_set ( access_token, refresh_token, expiry, etc.. ) you can store that securely and continue making offline_access api calls on their behalf. Note that you must programmatically refresh the token_set at least once every 60 days for it to remain valid.
I'd also recommend checking out the Xero supported libraries for help getting started quickly:
https://github.com/XeroAPI/xero-php-oauth2
https://github.com/XeroAPI/xero-php-oauth2-starter
Thanks to #droopsnoot for linking the video explaining how this works:
https://www.youtube.com/watch?v=Zcf_64yreVI

auth0 authentication for react-native-ios that communicates with php server

I am creating an react-native-ios app that communicates with a php web app hosted on azure.
How I understand it works:
The user signs up to the app, the server communicates with auth0 server which then returns a JWT token to the php server, saves the token to the database and then sends the token back to the client-device where it is then stored on device.
The user must send the JWT token as a header whenever communicating with the server.
Whenever the user logs out the token is deleted and when signing in, a new JWT must be received.
The user can sign in via using credentials that match what is on the database or sign-in with Google or facebook.
Or is Auth0 just for signing-in with enterprises such as Google or can I use it to sign in to my app also that has login credentials on the database?
I have found the
npm react-native-lock-ios but it doesn't work the way I described above.
In summary, How should I go about this and is what I have explained above correct?
The main problem here is that you did not understand how to work with JWTs. I would advise you to take a deeper look on how this technology works and how Auth0 can help you. But, in summary, this is the workflow for authentication that you must aim:
Your user will choose one of the many identity providers supported by Auth0(e.g. Facebook, Twitter, LinkedIn, SAML, WS Federate and so on).
Your react native app will communicate directly to Auth0 API through the react native lock.
Auth0 will interface with the chosen provider and redirect the user to an authorization page in this provider (case it is needed and it is the first time the user logs in).
Auth0 will generate a JWT and send back to your react native app.
Your react native app will send this JWT to the server (usually on the Authorization HTTP header) when issuing requests to your endpoints.
Your PHP backend will check if this JWT is really valid. This is can be done with Auth0 PHP SDK.
In case the JWT sent has not been tampered (changed irregularly), your backend will accept it as the user identifier and respond the request as expected by your react native app.
As you can see the biggest issue in the approach that you thought you would follow is that the login process does not go through your backend server. It happens on your front-end app (react native) communicating with Auth0 and the identity provider chosen.
JWTs are tokens that hold information (claims) about a subject. These tokens can be validated by anyone that possess a key (public or private). That is, having this key you can validate the token and can rest assured that it has not been changed improperly.
Further more, to answer the question regarding the usage of Auth0 with credentials on your database, you can bet that you can use it. Auth0 provides ways to integrate with your own database to check the existence of a user. This is called a customer user store.
Happy studying.

How to enable autologin on dropbox API

I am developing the API for dropbox in PHP,i have connected with the given steps and downloaded the files successfully but my request would be, when i am going to connect the api through calling one php file, it would be authorized using secret key, app key and token value and then waiting for authorize and force click to next for manual process if it is not in session.
I am going to setup this as deamon process, so i could not click every time manually while connecting the API on php, is there any possible way that need to be resolved for these kind of problems.
The user only needs to authorize the app once.
Once you have an access token for the account you want to use, you can just keep using that access token indefinitely.

Server-side Twitter client possible with OAUTH?

Twitter'll phase out HTTP basic authentication by August 2010. In the link my scenarios are from Desktop Applications. Basically my client should tweet new posts on a website.
This would be incredibly simple with HTTP basic auth, because I can store and use my account's username and password in the app to authenticate.
However, with OAUTH I can get final credentials by two means:
Callback method. You are redirected to Twitter, (login if isn't), click allow access, get redirection back to your callback URL.
PIN mode. You get a link to open, (login if isn't), click allow access, receive PIN code. Use this PIN code to authenticate your app.
Do I understand correctly that PIN codes also expire? How is it possible, given a username and password just to tweet from a client application? How can a server side script log in with the username/password and click allow access? All scenarios I could google up are for a web application to authenticate via twitter where the user is in front of the browser to walk through the redirect.
All scenarios I could google up are for a web application to authenticate via twitter where the user is in front of the browser to walk through the redirect.
The user has to be there to authorise you the first time (just as they'd have to provide you a username and password), but the resulting access token does not expire and can be reused (unless the user deauthorises your application, that is).
Store the access token - it's as good as a username/password. Better, actually - if they change their password, your access remains.
The PIN does expire under OAuth 1.0a. Using the verification code returned requires use of the temporary request token in the initial authorization request.
OAuth 2.0 defines more flows - one of which uses a direct login/password mechanism. It's up to Twitter to determine which flows they decide to implement. You can also embed a user-agent in the app.
Desktop apps suffered from a really bad user-experience with OAuth 1.0 which led to 2.0. It's doable, but painful. You can request XAuth access if you need to from Twitter as well. It's almost the same as basic auth.

Categories