I'm trying to use the Coinbase API for Ruby to create an application to accept Bitcoin payments. I assume one way I can use their API is through their OAuth sequence. So I created an OAuth 2 application on their site. It has these scope restrictions by default ...
• wallet:transactions:send is limited $1.00/day per user
• wallet:transactions:send:bypass-2fa is disabled
with a link that reads "Please verify your identity to upgrade limits." When I click on the link, it gives me two options
Buy limits (where I can upload my ID) or
Sell limits (where I'm given a link to "Verify my Identity")
Which of these do I need to use in order to achieve what I want?
According to the Coinbase documentation on Send Limits...
To better protect Coinbase users, the wallet:transactions:send permission requires additional OAuth authorize parameters and two factor authentication.
This implies that Coinbase limits the funds that are sent, likely to protect users from accidentally emptying their accounts by a software bug. However your app is being built to receive payments, which is not governed by this limitation. Your app should be able to receive payments as fast as they arrive!
Of course, when you try to withdraw funds from your account, you will run into these or similar limits. But that would be a great problem to have.
Related
Title says it all. Is it possible to send payments with a Plaid API developer account?
I am using developer account access tokens in Google Sheets and don't have a great way of hiding them. I'm hoping the developer accounts are read only so that if someone hacked me, they wouldn't be able to transfer money out of my accounts if they got a hold of an access_token.
Access tokens should always be stored securely. If an attacker has your access token, as well as your client_id and secret, they can make Plaid API calls on your behalf to get data for a specific Item.
The specific data that can be obtained from an access token depends on what products you are enabled for in Production. If you are enabled for Auth, this would include account number and routing number. This information can be used to request an ACH fund transfer via, e.g., your a website (note that this information is also printed on all checks in your checkbook). Finally, if an ACH transfer was made in this way, you would have grounds to have it reversed for fraud.
So while it might be possible for an attacker to use your access_token in conjunction with other hidden information (your client_id in secret) to get information that they could use to request a funds transfer out of your account, there are a number of hurdles for this attack vector. An attacker would also need your secret (or Plaid login info), and even then they would still only get the information that is present on every check you write, and there is a mechanism in the ACH system to reverse fraudulent transfers.
I want to get all the sign up & sign in with Google events of my Google Workspace users using API.
I can see the Tokens activity from my Google Workspace admin account, under the audit log (https://admin.google.com/u/5/ac/reporting/audit/token), but it's limited to first sign ups, and doesn't show any of the following sign in events of my users.
Is there any way to see all the events related to third parties sign ins / sign ups of my users? is there any place that lists the summary of all of the third parties linked to users in my organization?
As far as a summary, you can retrieve a list of applications authorized by your users using the Directory API tokens.list method.
Unfortunately when it comes to OIDC sign in events, there currently is no way to see when users are logging into a 3rd party application. You will see activity events for tools accessing Google APIs, but not for login.
I guess you could use tokens.delete to revoke access, making the users re-authorize to log in again (which will be logged). But that's a rather heavy handed approach.
I think I've found what you're after:
https://developers.google.com/admin-sdk/reports/v1/guides/manage-audit-tokens
You can use this api call to retrieve all authorization events for third party applications.
The general format of such requests is below (parameters are surrounded by a double asterix)
GET https://www.googleapis.com/admin/reports/v1/activity/users/all
/applications/token?endTime=**end date**&startTime=**start date**
&maxResults=**maximum number of events returned on a response page**
Hopefully this gets you the info you want. I don't have access to a google admin account myself so I can't test this api call.
I need to have access to Calendar information from a company's G Suite accounts, to synchronize data with the company system through a API.
When I need to provide access to my own data, there is a fairly simple way to do it. Using Oauth2, through a login window the user allows the API to access the requested data.
But in the G Suite documentation, the path indicated when involving the administrator and company data, involves the administrator accessing admin.google.com, go to the security-related session, and manually register my API, listing the scopes that he wants to grant me access.
To make a parallel, in Microsoft Graph there is a way to request consent from the domain administrator, where only a user consent / admin consent screen is displayed using Oauth2.
I wonder if there is a way to get this type of access in G Suite without requiring the end user to take such complicated steps to make my API work properly.
UPDATE:
This question was originally posted in 2019, does anyone aware if something was changes since then?
You should use the Marketplace SDK for this. This allows you to publish an application to the Google Workspace Marketplace where company admins can choose to install it for their domain.
There are a couple things to keep in mind:
There's an expectation that your application will have some sort of user facing presence (e.g. add-on, link to web app, etc).
Google will review your app before publishing. Since you're not using Gmail or Drive scopes (for these, Google requires a 3rd party security review), this process should not be too difficult. But plan for it to take some time, and follow the best practices so it's done right the first time.
You also mentioned synchronizing calendars. If that means mainly reading, no problem, but if you're writing (a lot at once), be mindful of calendar use limits. These are per user and for all activity by that user (not just your app).
Is there any way to find out number of users that authorized my application using Google API?
User can either install it from the Chrome Web Store or authorize it when going from URL, Chrome Web Store does show number of users who installed it but that most likely doesn't include all users using the app?
I'm not sure if this is what you mean, but you can go to your Google Developer Console and check your Quota usage for whatever particular Google API. This can give an indication as to how many users authorized your application through that API, since every time the API is accessed, it will consume quota. Quota resets every day though, so this probably won't give you an all-time number.
I am considering developing an application for the Apps for Business Marketplace. I see that new rules takes affect on November 19th. Referring to the new documentation (https://developers.google.com/apps-marketplace/) I do not see that any SSO requirement exists. There is allot of talk about migrating to new sign on methods, but I see no mention of sign on requirements.
What are the sign on requirements as of November 19th?
If SSO continues to be required or if I publish before Nov. 19th, my application requires security token from my API, in order to carry out API exchanges. To get this token a user/pass exchange is required one time. They would never need to enter a user/pass for my app after that. Will a one time exchange for the security token be denied under a SSO requirement?
For example the statement regarding SSO that an app cannot do is:
The end user should not be required to enter a username and password when invoking an application from within Google Apps. (https://developers.google.com/google-apps/marketplace/sso)
In my case it would not be required for the user to enter every time, just on the initial creation of the account. After that I would retain the token from my site, encrypted with the Installed App.
Would my app be denied for requiring this one time exchange under the SSO policy?
Mark
You will have to use SSO (or should if at all possible) -- see this part of the documentation: Besides, that is a better practice and should make your users feel more trust for your application.
From what I gather (note that I'm building my first marketplace app) you should not prompt users to enter username/password on your site. I am creating user record & storing token behind the scenes. So the user sees Google authorization screen, agrees to let my app use some data, accepts and sign-in right away without any prompt to create an account. After this, user will not be prompted in the future because I have their google id linked to a user record.
From their site - https://developers.google.com/google-apps/marketplace/sso#user_experience
As long as you don't have any intermediate screen, your app should be approved.