We are trying to implement OpenId in our application to connect to QBO. As an example we use code supplied by Intuit
https://code.intuit.com/integration/viewvc/viewvc.cgi/IntuitAnywhere-.NET/HelloIntuitAnywhere/HelloIntuitAnywhere/OpenIdHandler.aspx.cs?root=intuitanywhere&system=exsy1003&view=markup
The problem is that realmId is null, basically it doesn't come from the Intuit login page back to our app. All other data comes OK like Name, email.
We define attribute as
fetch.Attributes.Add(new AttributeRequest(
"http://axschema.org/intuit/realmId", true, 1));
I read that it was in bug in Intuit with regards to setting some cookies. Is it a problem or I am just doing something wrong?
I can post more code if need, but it's pretty much as in example supplied by Intuit.
When the customer authorizes access to their data through the 3 legged Oauth flow, the realmid will be on the querystring of the call back url that you provide.
The openId workflow doesnt always result in a customer selecting a QuickBooks company.
After the openid flow, call the javascript function direct connect(), you will get the realm id in the oauth flow as mentioned above
thanks
Related
I'm currently having users login to my site using Auth0's redirect functionality. It's great, but my past experince with google's oAuth tells me there's a problem. With my other site, we do the same login, the user gets a JWT and posts that to my API server. My API server then takes that token and contacts google to ensure this is actually a token that they made. And THEN, I give them a Bearer code that they can use for when they want to access the database.
With Auth0, I can't seem to find any way to contact them from my API server and say, "Hey, someone sent me this token, it checks out that it isn't corrupted, is for a data that is in the future and it says you are the issuer and it has the proper Auth0 client id. So, did you issue this?"
I must be missing something.
Thanks everyone.
I am using Shopify's OAuth for developing a custom Shopify public app and the OAuth part is working fine. I have used the state parameter to include the user id in the nonce value and then capture the user id from there so that I know which user to save that access token for. However, this seems really hacky to me. What is the standard way of doing it, ie capturing user id(User is a "user" on my application backend. The user id is his id for my application, not his shopify user ID) in this case? I am making the application fully REST API based so I cannot use sessions here. What is the general approach?
Here's the Shopify documentation on OAuth implementation. https://help.shopify.com/en/api/getting-started/authentication/oauth
Any help would be appreciated!
If I understand the question correctly, I don't think there's a more efficient/secure/non-hacky way of doing this other than how you're currently doing it. Ultimately you'd have to send something to Shopify, that Shopify then turns around and send back to you.
I'm doing a similar thing using the state parameter, but I'm encrypting the value (security by obscurity?) when sending, and decrypting when received. In my case, it's not a user id I'm using but a session id.
So I want to understand a little more about authentication in an API. I know very little about how security works.
I am using Auth0 for my app and it supports only logging in from a social media site. My API checks if a user is authenticated and checks data that is being sent to avoid wrong stuff to be saved in the database(mongodb). That is all I have currently implemented to secure my API. Is it possible that a user can take his own token that he got from logging in and post information to a different account by simply guessing a different user _id.
For example, an article receives all its content and the id of the article author.
If this is possible what are some solutions on securing my API.
Any other tips on making an API secure are appreciated!
Auth0 supports logins with anything , not just social networks. You can login with username/passwords, LDAP servers, SAML servers, etc.
A token is a secure artifact. An author cannot change the id in a token without compromising the token itself (e.g. the digital signature will fail), so impersonating someone else is not that easy. The very first thing your API would need to do is checking the integrity of the token being added to the request, and reject any that contains an invalid one (bad signature, expired, etc).
It is a question that requires a lot of content, so I would recommend starting here: https://auth0.com/docs/api-auth
What is the best practise for authorization and authentication of users in REST spring boot?
I am building web app with standard pages + REST API for mobile. I looked at many articles about Spring security and basically most of them goes with some sort of fitler approach that will allow or block REST calls. In my case, however, I have some auth logic based on who the user is. For example, there is a /update API that updates user information, and user can update himself, but cannot update other person.
Initially I thought to use next auth schema:
User calls auth API and pass name/password or cookie
System generates short life token, saves in it's database.
User get this token, updates his cookie (so JS in web application can read and use it)
When REST call is being make cookies are passed. At Controller, token is extracted, checked for expiration, query is done to database to validate token and get user id.
Based on user id, REST will be permited or blocked.
Is this the right approach to implement? I have a pretty big mess in my head after reading articles about spring boot security.
At least: session auth will not work for me (REST is stateless). I want to make auth for mobile device without storing login/password there.
Does it make sense to pass this token in the REST body itself? What in case of GET method?
Many thanks for sharing your knowledge.
Did you find a solution to your problem?
I have answered this problem elsewhere, if you are sure you won't want to open up the API to other developers/clients in the future (if you do then you should look at OAuth) then a simple token based solution will work.
Something basically along the lines of this:
Setup a standard html login page, that you can use for user login to the app
setup spring security to return a cookie on sucessful login with an authentication token
in your mobile app, embed a WebView (or equivalent) and load this login form - allow the user to login via that webview, on response grab the cookie and store the token (as mobile is generally single user, you can keep that pretty long to save mobile users having to keep logging in)
Add a security filter to the the REST API to authenticate against the token (from the mobile app pass the token in the header for example) - then you will be able to use normal spring authentication context for current users etc.
This approach is suggested by Google here: (EDIT: Google seems to have changed the page I originally read to be about using Google+ sign in and OAuth2.0 - I can't see a link to their general Mobile/API docs so here it is in the web archive :) )
I have also written up my implementation here:
Overview of the approach using Spring security
The code & details
Although this was really just an experiment/Proof of concept, it might be useful in your thinking.
Cookie approach seems perfect for the use case. Token can be tied up with user id. Filter can extract cookie and pass user id for example as header to apis - that should take care of GET...
Primary question:
Is there any (supported/non-hacky) way to use Quickbooks Online and Customer Account Data APIs without involving a browser at all, i.e. making an API request from a server?
Commentary:
The IPP docs only mention saml and 3-legged oauth, which seems to imply that any authentication and subsequent api calls must come from a browser.
Note that this is not satisfactorily answered by this:
How can I use API to get quickbooks data without browser based OAUTH?
, as that answer:
is not by Intuit and does not point to an Intuit source
suggests a hacky solution: a user/browser authenticates, after which the oauth/etc. credentials are stored and reused. This seems like a particularly bad idea for long-term use unless explicitly approved by Intuit, due to the fact that the apis may (and probably will) expire any oauth/saml tokens at some point.
No, to get accessToken and accessSecret you need to use a browser.
As you have mentioned, your 2nd option is the only way to achieve this. i.e reusing stored tokens.
PN - OAuth tokens are valid for 180 days. Before the token expires, your app can obtain a new token to provide uninterrupted service by calling the Reconnect API. You can automate this part by writing a small program which will call ReconnectAPI when tokens are older than 150 days.
Ref - Manage OAuth Tokens
You can generate OAuth tokens(for the very first time) from here - IPP OAuth Playground
CAD
Here, OAuth tokens are valid for 1 hour. After an hour, your application will have to issue another SAML assertion again to request a new OAuth token to use. The token should only be persisted during your user's session, and then destroyed.
Ref - CAD SAML
Thanks