The firm I work for sells and installs a website under the client's desired url. This is my first time dealing with any type of payment system.
I've created a SquareUp application in my own account but am lost as to whether each client website needs their own SquareUp application. I realize that there is the option for my SquareUp application to be given permission to access other SquareUp accounts.
Edit:
I think the OAuth API would work if I had many clients accessing the same website but each client has their own installed copy of the website we sell.
So lets say my firm makes a hotel reservation website that can be easily customized through settings. So we sell a website to Bob's Motel and his new url is www.bobsmotel.com and his web installation is complete separate from other of our clients.
In the SquareUp Application Dashboard, under my SquareUp account, does Bob's Motel get its own Application or does Bob in his SquareUp account create an application and I use those ID's in my settings file?
Square’s OAuth API will be what you’ll use to let up to 500 Square merchants authorize your application. Before you get started, please visit Square’s Developer Doc for more information about our OAuth API (https://docs.connect.squareup.com/basics/oauth/overview).
Related
I have built an API to my web application so that customers can access certain functionality without going through the dashboard. I have secured it by providing an API key to each customer that identifies them and restricts the IP address from which they can connect.
I have now had a request from a customer to allow them to access this API from their Salesforce platform. I don't know much about Salesforce, and when I asked them to let me know their IP address so I could create their API key, all they could give me was the list of reserved IP addresses published by Salesforce. This IP space is huge (millions), covering all of Salesforce, meaning that if someone gained access to the API key they'd be able to use it from any Salesforce account.
I have read some things about Salesforce having an OAuth service and having some kind of Application Connect service, but it mostly seems to be designed around allowing 3rd parties to connect to Salesforce - I'm getting a bit bogged down trying to determine if this is any use in my scenario (which requires authentication in the other direction).
I'd be grateful for any insight into whether there's something more specific I can do identify a particular Salesforce customer beyond simply putting dozens of CIDR blocks in my API key. I could ask my customer to identify themselves in the referer header when they call my API, for example, but of course that's trivial to spoof.
Thanks.
IPs can be spoofed too
Salesforce has a concept of "protected custom settings". You could make a "managed package" (Salesforce plugin, but you don't need to distribute it on their appexchange, Google Play/App Store equivalent), install it for the client and then enter the API key to the setting in a way that even client's sysadmins can't read it.
It'd be bit of work to set it up but might pay off if you think you'll get more customers on the platform.
How about a crude but effective iframe? or a link to your page they'd embed somewhere in their app?
Do you have just api keys? If you'd expose OAuth2 endpoint SF users could login to your app and then SF code could use access_token they got back instead of api keys. Or maybe you can protect access with certificate? Calling app would have to sign requests with a certificate. Client could upload it to their SF, you'd upload to your app...
You could demand the API calls to include the user's SF "session id" and you could use that to run some queries against source SF org. Org Id, user's login history etc things that are impossible to tweak even by sysadmins...
My client wants to build an website app that allows customers to link their Xero account to the website so that certain actions such as create/manage employees can be updated in the website and also pushed to the respective user's Xero account.
I've been through the basics of connection to the Xero API and had to create/install certificate and generate Xero keys etc to get both apps talking to each other. This is not a feasible approach for end users of the site trying to connect their Xero account as it requires sharing a key etc that is supposed to be secret.
Is there a way to create a connection using just some sort of Xero key - similar to linking Xero accounts? Or it the case that my client would need to become a Xero Partner and actually create an app that users can install from their Xero account?
The Xero API has a number of different types of applications - sounds like you've set up a private app, which (as you've spotted) is intended for interaction with a single Xero organisation.
To interact with multiple Xero accounts, you'll want to create a public app on https://developer.xero.com/myapps/. This will allow you to send multiple users through the OAuth1.0a auth process, giving you an access token for each account that has authorised your app. You can then persist these tokens and match them to the account in your own web app.
Note that this will give you access to each Xero account for 30 minutes before the user will need to authorise your app again. For long-lasting access tokens, you'll need to register your interest via the link in this page to get information on how to complete this process.
Is a Service Account intended to be created in an application’s domain? Or in a clients G Suite Domain, on behalf of the application?
Background:
My company has a product (hereafter “The App”) which has several thousand organizations as clients, each potentially having their own Google domains. (hereafter “Organization Domain”)
We are looking to set up a sync between The App and the Organization Domain, for data that is common between The App and the Organization Domain, and want to use an OAuth2 connection, with a domain admin granting The App ‘domain-wide authority’ on behalf of their users, for offline syncing.
From the Service Account page:
... an account that belongs to your application instead of to an
individual end user. Your application calls Google APIs on behalf of
the service account, so users aren't directly involved.
and
G Suite domain administrators can also grant service accounts
domain-wide authority to access user data on behalf of users in the
domain.
Referencing the Cloud Platform Console Help Faq:
You can access data from your users' Google Cloud Platform projects by
creating a service account to represent your service, and then having
your customers grant that service account appropriate access to their
cloud data using IAM policies. Note that you might want to create a
service account per customer... (emphasis added)
It sounds like The App should be able to create a single Service Account, which all of our clients authenticate into for their Organization Domain.
The part that’s unclear:
In the Service Account page, the instructions for delegating domain wide authority seems to shift concerning where the Service Account is.
Before the instructions, it reads:
... first enable domain-wide delegation for an existing service
account in the Service accounts page ... with domain-wide delegation
enabled. Then, an administrator of the G Suite domain must complete
the following steps:
Afterwards, it reads
Your application now has the authority to make API calls as users in
your domain (to "impersonate" users). (emphasis added)
From what I’m reading, the first part reads "one Service Account for The App", while the later reads as "the service account is only able to access as a person on The App domain, rather than the Organization Domain."
Is a service account intended to be created in The App's domain? Or in the Organization Domain, on behalf of The App?
I have seen examples that have the Organization Domain admin create a service account, and then pass over the clientID/secret to the owners of The App… but I’m not sure that’s the correct approach for our scenario.
Related - Scope management:
The delegation steps have the Organization Domain admin manually add scopes.
We’d prefer to use the OAuth consent screen, which shows the scopes, and has our pages/policies linked.
Unfortunately, as far as my research has uncovered, it doesn’t look like that page is used in the Service Account authorization flow; just for other application types, which authenticate a single user, as opposed to an entire Organization Domain.
Is there a page I’ve missed in Google’s sea of documentation?
I think you are miss understanding the use of Service accounts.
Service accounts are dummy user accounts. They have their own drive account, calendar account and probably a few more. Service accounts are designed for use with back end applications server to server communication where there is no user interaction. Service accounts are preauthorized. You grant the service account access to the user data in your case by using domain wide dedication to the gsuite account. This way the service account would be able to for example send control all the users google calendar accounts.
This is why you dont need a consent screen. Another point with service accounts is you must control the data in order to set this up. If you dont control the data then you cant grant the service account access to that data.
You should be using Oauth2 if you want to access private user data owned by your customers.
As for the rest of your question is very broad and i am not really user where to start with it you might want to break it up into several questions. Take them one at a time. I am not sure i understand what it is you are trying to do so i dont think i can try to answer that part.
I'm looking for a solution where a customer will fill out a payment form (subscription base) and customer information form on my website. The payment will go to the QuickBooks Merchant Service and charge them every month automatically. We will also add the customer info to QuickBooks Online.
How can I do this without a sign in process since the customer will have no QuickBooks account or QuickBooks Merchant account. Also can I achieve this with no e-commerce storefront like BigCommerce.
I tried using the QuickBooks PHP DevKit "consolibyte/quickbooks-php" and everything works but you have to sign in first.
Thanks.
I was searching some more and will this help me out > "QuickBooks PHP DevKit for the Web Connector". I'll keep reading the docs.
How can I do this without a sign in process since the customer will have no QuickBooks account or QuickBooks Merchant account.
Use this library:
https://github.com/consolibyte/quickbooks-php
And follow the quick-start guide here:
for QuickBooks ONLINE: http://www.consolibyte.com/docs/index.php/PHP_DevKit_for_QuickBooks_-_Intuit_Partner_Platform_Quick-Start
for QuickBooks for WINDOWS: http://www.consolibyte.com/docs/index.php/PHP_DevKit_for_QuickBooks_-_Quick-Start
Also can I achieve this with no e-commerce storefront like BigCommerce.
Yes.
everything works but you have to sign in first.
You have to sign in ONCE. Exactly ONCE. And then you NEVER NEED TO SIGN IN AGAIN. Of course you have to sign in at least once - how else would QuickBooks know that it's actually you wanting to exchange data with QuickBooks, and not some random hacker half-way across the world?
The sign-in is to authenticate and connect to QuickBooks THE VERY FIRST TIME ONLY. After THE FIRST SIGN IN, YOU NEVER HAVE TO SIGN IN AGAIN and can communicate without a sign-in.
This is standard OAuth, like every other OAuth platform on the planet. You sign in once to a authenticate yourself, and then you can do whatever you want from there on out.
I am developing a web app that will be working with other companies web apps. Part of the desired user experience is that users on our web application will be able to log into our app, and be able to visit our parters' web applications. Accounts will be automatically created for the users on our partners' sites. We'd like them to be able to enter the partner sites already authenticated, without having to log in or authorize anything (like with OpenID or OAuth), similar to the relationship between a bank and a credit card rewards program. Is there an existing standard that covers this?
Single Sign On often used for such functionality.
There are a lot of implementations.
I used in production Jasig CAS