Action Required: OAuth redirect_uri must be configured in application settings

(Spencer Hunter) #1

In our constant effort to improve the Dwolla platform, we are introducing a change that will strengthen the security of our OAuth service. We will soon require that all applications using OAuth have an OAuth Redirect URI set in their application settings. Applications creating OAuth authorization requests must use the same redirect_uri that has been set in their application’s settings. This requirement will go into effect on November 2, 2015.

If you don’t already have a OAuth Redirect URI set, follow these steps:

  1. Sign in and navigate to your registered applications page.
  2. Click Edit Details next to your registered application.
  3. In the OAuth Redirect URL field enter in the redirect URI we should direct the user to once they have authenticated via OAuth. The redirect URI in your application settings must match what you pass into the redirect_uri parameter in OAuth authorization requests.

If you have any questions or feedback, please reach out!

Fatal error: Class 'GuzzleHttp\Client' not found
Fatal error: Class 'GuzzleHttp\Client' not found
Refreshing token returns null, authenticating says i have wrong redirect uri
(Brian Holub) #2

Quick question… I’m starting to work on integrating Dwolla into our “marketplace” type application. Currently “buyers” and “sellers” (or “senders” and “receivers” or whatever) are different flows and have different redirect URIs. Will the change require an exact redirect URI or just matching domain?


(Spencer Hunter) #3

@bholub Great question, thanks for bringing this up. We will compare: protocol, subdomain, domain, tld, and file path. (Querystring parameters are ignored). If you have different flows that require different redirects, you can include multiple URLs in a comma-separated list in the OAuth Redirect URL field.

(Spencer Hunter) #4

Note: This is available to test against in UAT. If you do not have the redirect_uri configured in your application settings you will be met with an error upon redirecting to Dwolla.

Can anyone tell me if the sandbox service is up or down?
(Øystein Sunde) #5

Does this mean the that testing sandbox from localhost no longer is supported?

(Brian Holub) #6

I’ve tested with local (non-internet accessible) URLs and it seems to work fine… although I haven’t tried just “http://localhost” – I think you just need to pass in a matching URL when you send redirect_uris

(Spencer Hunter) #7

@Oystein_Sunde localhost is treated as valid when setting your OAuth Redirect URL.
For example, I have an app set up with localhost being included…

(Spencer Hunter) #8


In the interest of the developer community, we are extending the deadline to implement this change in production from September 14th to November 2, 2015. Please note: This is available to test against in UAT.

(Jerry Johnson) #9

So how would this work with a rich client application? We have a different type of flow where a Windows app needs to prepare requests using the API. The Windows app cannot receive any responses other than the stream that is already opened by the request. In other OAuth implementations we have been able to use a URN syntax and read the Window title to get the key. How should we accomplish this in light of the Callback URL requirement?

(Gordon Zheng) #10

Hey @Jerry_Johnson,

Thanks for the note. You can still use something like oauth2:return/foo or http://localhost/foo as a redirect_uri. We have no restrictions on the protocols you can use. I think this is the same approach you’re talking about, but if not I’d recommend this:

Does your application have a backend server?

(Rodion Vshevtsov) #11

@spencer You’ve noted that Dwolla compares protocol, subdomain, domain, tld, and file path. This point is also mentioned in the documentation. But I have a problem with that.

There is OAuth callback URL defined in Dwolla’s application: When I make a request to defining redirect_uri as everything is ok and I get a code. But when I’m trying to get tokens using this code and the same redirect_uri I get the following error:

{"error": "access_denied", "error_description": "Redirect Uri does not match redirect uri associated with token."}

If application’s OAuth callback URL is set to everything works fine. It looks like additional parameters in query string are compared too.

Thanks for any help.

(Spencer Hunter) #12

@rodion Thank you for your message. I want to point out that there are two comparisons that occur regarding the redirect_uri. The error you are showing is an error that we will throw when the redirect_uri parameter in the [authorization request][1] step does not match the [finish authorization][2] step of OAuth.

  • Comparison 1: Matching what you are passing into the redirect_uri parameter in the initial [authorization request][3] to what you have set in your application’s settings. (Comparing: protocol, subdomain, domain, tld, and file path. Querystring parameters are ignored)
  • Comparison 2: The redirect_uri that you are passing into the [finish authorization][4] step must match what you passed into the initial [authorization request][5] step of OAuth. (Must be identical. See below for more info)

According to the [OAuth2 spec][6]:

         REQUIRED, if the "redirect_uri" parameter was included in the
         authorization request as described in Section 4.1.1, and their
         values MUST be identical.

Let us know if we can provide additional clarification!

Oauth with query parameters
(Rodion Vshevtsov) #13

@spencer Thank you for your reply. I’m really sorry, but it seems it was my bad. I many times checked out OAuth redirect URLs I sent in authorization and finish authorization requests and now figured out that double-escaping was applied for OAuth redirect URL in finish authorization request (mine and library’s one). So now it works like a charm. Thank again for paying attention to the problem.

(Jackchang) #14

@spencer I understand that I can include multiple URLs in a comma-separated list in the OAuth Redirect URL field, but we have many subdomains, and some subdomains are created on the fly, can we use wildcard. i.e., * ?


(Spencer Hunter) #15

@jackchang We don’t allow for wildcards to be used within the URL, however this is something I will take back to our team for consideration! One solution I mention in the thread below is that you could set the redirect_url to one URL and have that return another redirect to the appropriate URL.

(Jackchang) #16

@spencer Thanks, I guess this is the only possible solution for now.

(Dennis Nadeau) #18

I have problem with getting the auth code. I use the code from the example, replace it with my Key&Secret and redirect_uri,
but the link takes me to this page:

$OAuth = new Dwolla\OAuth();

$OAuth->settings->sandbox = false;
$OAuth->settings->debug = true;

$OAuth->settings->client_id = “zbDwIC0dWCVU7cQtfvGwVwVjvxwQfjaTgkVi+FZOmKqPBzK5JG”;
$OAuth->settings->client_secret = “ckmgwJz9h/fZ09unyXxpupCyrmAMe0bnUiMHF/0+SDaR9RHe99”;


OAuth assistance - utilizing dwolla-php
(Corey Spitzer) #19

I’m using a call to genAuthUrl() provided by the dwolla-php library, passing one of two redirect URLs for my different flows. Both of the redirect URLs are in my comma-separated OAuth Redirect URL value for my app in the sandbox environment. They are of the form http://localhost:2025/{user_type}/payments/onAuthorizationComplete where {user_type} is one of two strings. The problem I’m seeing is regardless of which flow I use, the first redirect URL that’s in the configuration value for my Dwolla application (via{id}) is used. I’ve confirmed that the URL generated by the genAuthUrl() call is correct and I’ve tried simply changing the order of the URLs in my Dwolla application configuration without changing my code to confirm only the first URL is used. Please advise.

(Spencer Hunter) #20

Hi @coreyspitzer,

After looking into our logs it appears that the value you are passing in to the redirect_url param doesn’t match the url shown in your post. I see either HTTP/1.1://localhost:2025/{user_type}/payments/onAuthorizationComplete, HTTP/1.1://localhost:2025/payments/onAuthorizationComplete, or http://localhost:2025/payments/onAuthorizationComplete as values being passed in. The value has to match exactly from the protocol up through the file path.

(Spencer Hunter) #21