`send:bypass_2fa` scope is only allowed for reviewed applications

I am attempting to apply the send:bypass_2fa scope, but when I do I get the following error in the authorization screen:


I viewed my application, but do not see where it can be reviewed. How exactly does this occur?

Thank you for any assistance you can provide.

Hello @Mike-E! Thank you for taking an interest in trying out Coinbase APIs. For the details regarding your concern, we will check on this for you with our team. We will get back to you once we have more information. Keep in touch!

3 Likes

Hi @HakunaMatata I wanted to check in on this issue. Thank you for any update you can provide. :pray:

1 Like

Hi @Mike-E! Thank you for checking in on this topic.

After following up with our product team, we have been informed that they are planning to deprecate this scope by end of year, due to the risk it can be used by attackers to skip 2FA to takeover an account and withdraw user funds without friction.

As they are planning to deprecate the send:bypass_2fa scope, there are no plans to update that error message at this time.

2 Likes

Well, except for the other fully friction-inducing and overly-protective setting that you have employed with wallet:transactions:send is limited $1.00/day per user :stuck_out_tongue:

I am really disappointed to hear about this development. This is causing a huge headache for me. Consider that for my application:

  1. I create an access token for the exact amount needed to transfer (This is currently rebuffed with the above setting as captured here)
  2. Transfer the value
  3. Revoke/invalidate the token immediately after usage

It’s also frustrating to see the desired behavior implemented in Coinbase Exchange/Pro APIs.
They are excellent! Yet the Coinbase Retail APIs are holding up the show here with these overly burdensome and difficult-to-use scopes and restrictions.

3 Likes

And another thing :grin:

Consider that in my case I am sending Coinbase-to-Coinbase. So, the value is staying within your system with an identified email address/username. I think there’s a difference between sending in-network, and out-of-network (crypto address). Sending out of network is what a bad actor would do.

Sending in-network should be 2FA optional and sending out of network should be 2FA required. Thank you for your consideration.

3 Likes

Completely agree Mike, this is not supporting legitimate commercial based systems at all and there needs to be a way to make this happen.
The original idea an app could be reviewed/approved was fine, happy to go through some due diligence to provide comfort we are a legitimate businss.,
But turningn the whole thing off is not sustainabale. We plan to have thousands of users who have signed up to our service - how is this going to work with a 2fa token blocker that we can never receive, even though the user is signed up to our service and allow payment ?

1 Like

Indeed @fran.meggs there are two models here. One is the blanket/approved limit and the other is a per-authorization model. It cost me a lot of time and effort to implement the per-authorization but after using it for a few years it’s been sort of nice to know that for that particular authorization there can only be $X moved.

However, I am not sure that makes up for the disruption of not having an end-to-end process where authorization is unnecessary in the first place. I have this for PayPal Payouts and also (ironically) for Coinbase Exchange to get the money in my Coinbase Retail account for the payout (I think I mentioned it above).

Interestingly enough, Coinbase recently overhauled its approval process. Or rather, I should say, they deployed breaking changes in the previous per-authorization model and are currently attempting to define an approval process. It’s a gigantic mess right now (my application has been hosed for over a month) and you can follow along/vote here:

1 Like

@Mike-E
Have just upvoted for it now.
Sounds like there is a wait-and-see on this for a few days at least and see where it lands.
Can I test my understanding of the as-is situation with you :

  • right now apps will have a $1 a day limit in place
  • send requests will work up to $1 a day without a 2fa token request issued
  • if a subsequent send request exceeds the $1 in a day limit, only then the user will be notified and a 2fa token will be requested

Is that your understanding ?
Thanks
Fran

Thank you very much, it is appreciated. :pray:

As for your points, a discussion is OK as there are lots of moving pieces here. It took me a while to wrap my head around how all pieces play.

right now apps will have a $1 a day limit in place

Correct. But keep in mind this is not the app that has the limit, but rather the limit the user places on the app to send on their behalf. The user must connect with your application and if the wallet:transactions:send scope is applied (which it will be in this case), the authorization screen provides them with the ability to specify the maximum amount per day the application can send on their behalf.

Right now this is a mess because not only is it pegged to $1/month (and yes not per day, it’s one of the many identified issues with this new selector)

send requests will work up to $1 a day without a 2fa token request issued

All send requests ATM always require a 2FA code from the user regardless of the amount. It’s a required parameter. At least, that was my experience when putting it together 2 years ago. I doubt it has changed.

  • if a subsequent send request exceeds the $1 in a day limit, only then the user will be notified and a 2fa token will be requested

So keep in mind everything is scoped per-authorization. The token you get back after the user authorizes to send is what has the limit applied to it. You use that code to compile your request and call the API. So if there is only $1/day limit on the token and you try sending $2 in the same day with the same authorization token, it will fail.

1 Like

Hi @Mike-E, yes definitely a worthwhile discussion.

Things have changed or changing, or both.
Re: all send requests ATM always requires a 2FA code :
I have multiple examples over the last 7 days were Send requests have successfully sent on payments with the need for a user generated 2FA token.
Right now :
It is only since 8am GMT this morning, since Send requests are now failing, request a resend with the 2FA user token required.
In general :
I don’t see why every Send request needs a user generated 2FA token, if they pre -approved the $1 limit ?

Ideally :
IMHO, a usable process is

  1. a send limit of X where up to X per day/per user can be sent without 2FA
  2. the send limit is something you can set in the authorisation to the user and they decide to accept it or not
  3. an app should be designed to stay within these limits or else notify the user as needed.

Cheers
Fran

Agreed. I like having the limit that I apply per authorization (mostly because I put so much time into implementing this and learning a lot about Oauth2 workflow), but I do not have to do this for PayPal and I do not even have to do this for Coinbase Exchange transfers. There’s a lot of room for improvement here, and it seems like it’s going to get worse before it gets better.

2 Likes