Please allow mobile deep link redirect urls

Currently the redirect_url must have an http or https prefix. This means that in order to use the Blizzard API you must have some sort of apache redirect kung-fu to make it back to your app and breaks most oauth libraries meaning you also have to use webviews and store the tokens yourself.

Most other oauth providers allow for any redirect urls so it’s not exactly clear what the concern is in this scenario.

Would love to hear it.

1 Like


I’d be really interested in having an anwser to this question as well.

Any news ?

See you

Hello, '19

same here. Now I need to program stuff in such a dirty way.


This is most likely by design. Since the ToS does not allow you to ship your client credentials it would not be useful at all.
Allowing custom URL schemas would lead consumers of the API to ship their client credentials within their mobile apps. Doing so would not only be a ToS violation but would render it impossible for the developer to properly control the rate limit of the API since multiple devices could be consuming the API at the same time.

Basically it seems this API is designed to force every application to have their own back-end server dealing with tokens and rate-limit.

Okay. I know I’m late with this but while I’m at it I want to address what I found out while trying to get around Blizzard’s limitation.

From what I’ve read (I would send links but apparently I’m not allowed to), you should know two things :

  1. deep links are not secure, they’re basically as opaque as non secure http get requests and
  2. OAuth 2.0 can be implemented with deep links using PKCE

However the Blizz API doc does not give any indication on PKCE. Also, the returned code is a one-time use and it requires both client_id and client_secret to be consumed so I still think Blizzard should allow deep links. Regardless, here’s how I plan to get away with it (as securely as I can) :

  • instead of using deep link in the API redirection, I redirect to my own server (the app that holds the client_id and client_secret) via https. Optionally you want to do some treatment here.
  • then my server redirects the user to deeplink with authorization code as parameter.
  • Optionally, if you are not confident with previous step, you must send a single use token that holds the blizzard authorization code secured in the payload as deeplink parameter.
  • then use a callback on the user’s side and send back the token to server with POST method.
  • in a middleware, exchange auth code for a user token and finally
  • return a proper JWT containing both the battletag and the blizz token in its payload as response to the previous POST request.

Final advice : If you want a deeplink then you’re obviously on mobile. Don’t store JWT in the browser neither as a cookie or in web storage because of CSRF and XSS attacks. Use the native platform’s cache or even put a .whatever in the filesystem I guess… But don’t put it in the browser.

Obviously if you’re able to parse the redirection’s request parameters then you can save a lot of steps. But I wasn’t able to so… Here goes.

There’s nothing stopping you from hosting your credentials on a server somewhere, for your mobile app to fetch before doing all the auth steps itself.

When this came up years ago, I threw together a quick nginx config to redirect to custom schemes. I no longer host the service but you can find how it worked here:

Edit: I just rehosted it here for funsies: