I am working with Bigcommerce api using oauth. I am currently in development phase. I have given auth callback url as
http://localhost:3000/resource_callback.
I am unable to get store hash in context. It is only sending scope, and code. What am I missing here? Just using http instead of https is the reason? Please help me with proper direction.
If you are receiving the Auth Callback Request but it only has code and scope query properties then the problem is how you are installing your app. At this time it is necessary to install an app directly through your store's Control Panel, rather than using a link to do the install (as is common with most oAuth implementations). The use of a link for the install is something that will likely be added in the future but oAuth on BC right now is geared towards public applications installed through the store.
That being said, it is possible to make oAuth credentials for a store even without making it a public application. Please follow the long answer seen on this question:
Can BigCommerce Private Apps use OAuth
This will cover the full process for generating oAuth API tokens from registering an app to installing into a store and beyond. Based on your question you should start at the Generate the Auth Callback Request section. If you follow the steps there then your Auth Callback Request will include the context property as well as the other two.
Update
You can now generate oAuth tokens in a store from Advanced Settings > API Accounts. As a result it is no longer necessary to install a draft app into a store for the sole purpose of generating oAuth tokens. You will still want to do this if you are developing an app for the BC App marketplace or developing a user interface for your app that you want to live in the Control Panel of the store.
Just went through the same thing. See here: Bigcommerce Authentication code. Let me know if you need more details. SSL is mandatory.
Related
I am using electron to build a little desktop app to interact with my laravel backend. Im using laravel sanctum here so I can easily get a personal access token via https and then make authorized api requests with it. The token will be stored using node-keytar (main process). I am also using vue.js on the frontend of the electron app.
Now my question is: Do I need to make all authorized api requests in the main process and send the received response via ipc to the renderer process? Or is it safe to make authorized requests (with the personal access token as Bearer token) in the renderer process? Because on the one hand I ve read that as much as possible should be done in the renderer process to ensure performance. But on the other hand I don't know if the token could be intercepted somehow and I can't find much information on this.
Can someone help Thanks in advance!
It is pretty standard for a native client to send tokens directly from the UI to APIs - that is how non Javascript desktop apps would work - eg if coded in Java or C#.
Of course, for an Electron app node integration should be disabled in the renderer process, so the privileged code to use keytar has to run in the main process.
SOMETHING TO COMPARE AGAINST
There is a sample of mine here that uses OAuth for desktop apps with Electron, and keytar for token storage. I call APIs directly when getting data for views, and need to call from the renderer to the main process to deal with token storage.
I have a question about fusionauth and its 2FA API.
we want to use 2fa in our app but only under some circumstances and not on every login.
I found that there is API to send a code via SMS but I can't seem to find an API to verify it.
can anyone help me?
I looked at the docs and there is only send and enable/disable no verify, can it be somewhere else?
The API does support a trust mode, but there is not currently a separate API for selective 2FA.
There is not an API to validate the code, instead you utilize the Two Factor Login API to complete the login process. This implicitly validates the code.
https://fusionauth.io/docs/v1/tech/apis/login#complete-two-factor-authentication
We have an auth infrastructure based on OAuth2 that is integrated into a variety of web apps within our organization. We also have a pure native application with no middle-ware of its own, and we want to integrate authentication into this native application. This application already has its own internal login mechanism with a native login screen, and we don't want to have it start launching external components like web browsers in order to display login windows. We are both the app provider and the auth provider, so the concern of the app having visibility into the user's credentials is less of an issue -- we trust ourselves to not intentionally do anything untoward with the user's credentials, and it's the same people writing a login form in the app as writing it on a web site. :-)
We are trying to figure out how best to support having the application continue to collect credentials the way it does now, but use them to obtain an auth token within our auth framework. With the APIs in place right now, the only way I can see for it to be done is to bake a Client Secret into the native app so that it can use a Resource Owner Password Credentials Grant request, since the code that would normally be making this call doesn't have a server side to live in. This feels really wrong, somehow. :-P
As far as I can see it, many of the structures of OAuth don't really apply to this app because it's not living in the context of a web browser, it doesn't have any concept of a "domain" nor any sort of "cross-domain" restrictions. It has been suggested that perhaps we create middleware for this app just for the purpose of exchanging authentication codes for tokens, but the rationale for that seems to be that this middleware theoretically ought to be able to somehow vet requests to determine whether they are legitimately from the application, and I don't see any way to do that that couldn't be faked by anyone with access to the client application code. Basically, the only purpose such middleware would serve would be to make the Client Secret irrelevant with respect to getting auth codes for credentials.
One thought that came to us was, how does something like Windows do it? Windows very obviously uses a native login form, but then some flow exists whereby the credentials that are entered are used for authentication and presumably, deep in the internals of the OS, for obtaining an auth token. Does anybody know if this architecture is documented anywhere? Does Microsoft's architectural choices here have any relation to OAuth2? What is the "best practice" for an application if you take it as a given that it doesn't have middleware and has its own native login form?
FWIW you don't need a client secret to use ROPC Grant to obtain or refresh tokens if the client is configured as a public client, i.e. a client that isn't capable of storing a secret.
RFC8252 OAuth 2.0 for Native Apps encourages using a native user agent for your scenario, using authorization code flows with PKCE. Authorization services like Okta and Auth0 have jumped onboard too, although they still recommend ROPC if the client is "absolutely trusted".
RFC6819 OAuth 2.0 Security discourages ROPC, but also says "Limit use of resource owner password credential grants to scenarios where the client application and the authorizing service are from the same organization", which are first-party apps.
So while the security verdict seems to be that authorization code+PKCE is the best practice, the UX hurdle of showing a user a browser window to log into a native app seem to be keeping ROPC alive. It's difficult to tell if that UX is jarring because people aren't used to it or because people can't get used to it.
This question already has answers here:
How do I authorise an app (web or installed) without user intervention?
(2 answers)
Closed 5 years ago.
I have a client id and client secret for my Google Container Engine app obtained via Credentials and I just want to do some local testing of the JSON API endpoints.
How can I convert this into a Bearer token so that I can just get some work done? Is there a Google page where I provide these things and get a token that I can use in my app?
I don't want to have to write an entire OAuth handling mechanism at this point in time (which would use the flow described in oauthplayground). It's an app to be run only for my account, in headless mode, on a trusted machine, to manage my cluster.
NOTE: must not require any proprietary software installations (e.g. the Google SDK).
Google provides an API Client Library for Java, which itself depends on an OAuth client library.
For the project of 9Cards launcher for Android, within the back-end, we had to use this library to fetch applications usage statistics from Google Analytics. In our code, because it is a case of "server to server" authentication, we use a Service Account's credentials. The code issues a request from Google a short-lived OAuth2 Auth Token. The library may provide similar features if you use a Client-ID and Client-Secret.
Regarding the issue of licenses, the library is published under Apache License v2, so in that regard it is not too proprietary.
I have a client id and client secret for my Google Container Engine app obtained via Credentials and I just want to do some local testing of the JSON API endpoints.
Good start. I guess by "the JSON API endpoints" you mean the Google APIS. Make sure you created OAuth Client IDs and not one of the other options.
How can I convert this into a Bearer token so that I can just get some work done? Is there a Google page where I provide these things and get a token that I can use in my app?
Yes the OAuth Playground will do that for you. The detailed steps and sample code to consume the token is at How do I authorise an app (web or installed) without user intervention? (canonical ?)
I don't want to have to write an entire OAuth handling mechanism at this point in time (which would use the flow described in oauthplayground).
Follow the steps linked to above and you will see that you don't need to write any code at all. Once you have the refresh token (a one time procedure), you're all set. I exaggerate slightly, you do need one line of code to post the refresh token to the Google Oauth endpoint to fetch an access token. See the bottom of the linked answer for an example. Or you could just compose a curl to do it from the command line and put the Access Token into an environment variable.
I just wanted to avoid the whole thing and get a code printed on the screen
A bit like https://youtu.be/hfWe1gPCnzc?t=198
I'm working with a Point of Sale computer that is exporting a CSV file. I want to parse that file of inventory items. I want to download the product (search by SKU), update it with whatever is in the Point of Sale system, then send the updated product back to BigCommerce's API.
It seems like the whole API framework is designed around "apps" that end up in their appstore, of which this isn't the case at all.
I want to install a small .exe on a retail Point of Sale system that does an API call, not turn it into a web server and have to put SSL on it.
Is there a more straight forward way to work with the BigCommerce API then their "app store" route?
More digging around, I came back to this. So you really can't have any code running that isn't on a publicly available web server, even when you're developing? That can't be right.
To integrate with our single sign-on flow, your app must be a publicly
accessible web application. Choose your preferred language, framework
and hosting solution, and go from there.
If you do not want to set up an "app" using OAuth and an SSL certificate for your code you can use the Basic Authentication method for now. Note that this is deprecated and I do not know when exactly they will discontinue this method of authentication. If not wanting to go with SSL and an app at this point that is your best option.
Otherwise you can look at a self-signed SSL certificate if the app is just for your own code but this would again require setting up an app.
I faced a similar situation as yours. You can implement a oauth2 callback by setting up a SSL site on your machine using a self signed cert, say on port 8000. Then, while using the store owner creds 'install' your app from the my apps dashboard to obtain your token.
This is all assuming you've setup a page to handle the callback request and exchange the temporary token for your permanent one.
It's a bit painful starting out but once you get going its not so bad. I did everything in .NET.
Based on my discussion with their API team I wouldn't waste time with basic authentication if you're just starting out since you'll have to convert sooner than later anyways.
You definitely don't need a public SSL callback URL though if you aren't looking to create an app for their marketplace.
Hope this is of some help.