POST https://uat.dwolla.com/oauth/v2/token returns with blank "scope" (White label)


(Nikhil Desai) #1

We are currently evaluating Dwolla white label solution. As part of the flow, we want to create a Customer and then attach a Funding Source to the customer.

In order to create a customer, we first need to create an access_token. In the UAT environment, when I create a token using: POST https://uat.dwolla.com/oauth/v2/token, I do a get a valid response with an access token but the scope is always an empty string “”.

When I use this token, the ‘create customer’ operation doesn’t work and I see this error:
{“code”:“InvalidTokenType”,“message”:“The requested endpoint requires an account token.”}

Note that I have selected all the permissions (including Manage Customer) for the Application for which I am generating the token using its id and secret. Do I need to do something else?

Thanks!


Uat-dwolla auth v2 returns a blank scope
(Stephen Ausman) #2

Hey Nikhil,

It sounds like the token you created is an application token. Application tokens can only be used for managing webhook-subscriptions and events on behalf of your application. In order to create customers, funding sources, transfers, etc. on behalf of an account you will need an account token. You can get an account token at https://uat.dwolla.com/applications, or by going through the 3-legged OAuth flow detailed here. Let us know if you have any questions.


(Nikhil Desai) #3

So, just to confirm: If I want to use the white-label API (v2) and handle creation of customers, funding sources and money transfer then there is no automatic way to let my application create an access_token, correct?

Would these be the steps?

  1. Go to https://uat.dwolla.com/applications and create a token for my application
  2. Keep refreshing the access_token using the refresh_token provided in step 1

Since refresh token is valid for 60 days, would I need to do step 1 above every 60 days in order to obtain a new refresh_token which my application can then use to get the access_token?


(Stephen Ausman) #4

Almost,

2: Keep refreshing the access_token using the refresh_token provided in step 1

Since refresh token is valid for 60 days, would I need to do step 1 above every 60 days in order to obtain a new refresh_token which my application can then use to get the access_token?

You will only be able to use the refresh_token provided in step 1 once. When you exchange the refresh_token from step 1 for an access_token the response will also include a new refresh_token value that can be used the next time. The refresh_token from step 1 will be invalidated once it’s used, but you will not need to do step 1 again if you save the new refresh_token provided in the token response.


(Nikhil Desai) #5

It would be great if there is a way to programmatically generate the tokens in the first place.

Also, what does the 60 day validity mean for the refresh token? I noticed that if the token is not used within 60 minutes, then I have to generate a new one from the web page.


(Spencer Hunter) #6

We’re working on providing an alternative auth for White Label applications which allow you to programmatically obtain an access token that can be used to call the API. Stay tuned on the forums for updates on this front.

The 60 day ttl for the refresh token means that the refresh token can be used anytime up until 60 days to generate a new account access token and refresh token pair. A refresh token is paired with an access token solely for the purpose of refreshing authorization on your issued token set. For white label applications it’s not likely that you’ll make it 60 days without refreshing your token set as this type of integration is highly dependent on calling the Dwolla API.


(Mark Schaake) #7

Is there any news on simplifying auth for white label? I just deployed to production using access tokens only because it worked in the sandbox, only to find that it doesn’t work in production. I’ll move to the OAuth dance for now, but would like to know if the Dwolla team is still working on a change for white label. Thanks in advance.


(Spencer Hunter) #8

Following up on this post. ManageCustomers is a private permission that is enabled by the Dwolla team once your app has been approved to go-live in production. This permission is enabled by default in our Sandbox environment. There are no updates with regards to auth for white labeled apps that use our Access API, however this is something we’re continuing to evaluate. The recommended auth will involve obtaining an application access token.


(Mark Schaake) #9

Thanks Spencer. All is working now that my account completed the approval process. No need for the OAuth dance, all requests work with the white label account access token.