Concerns/Issues with Client Secret Requirement for Community APIs

API Discussion
It appears the client_secret is required for any use of the new APIs. This results in several types of applications becoming either 1) invalid under the API terms or 2) overly complex for users and developers.

There are two connected questions that many developers are already very worried about, especially with only 3 months before the existing API cutoff:

  • Can I choose to publish my client_secret knowing the risks?
  • Will there be a method to get an access token without a client secret? If so, will this be available before Jan 6, 2019?

Off the top of my head, there are several types of applications that are facing these issues:

  • Static website
  • Local application
  • Standalone native application
  • Shared/copyable web application (Google Sheets, Glitch, etc)

Basically, any application that doesn't have their own dedicated backend will be facing these issues.

To note upfront, the Battle.net authorization for users of these systems does not address these issues as it requires the application to get an access_token which requires the client_secret. Requiring "normal" users to generate and enter their own developer clients is also highly undesirable.

As far as I can tell, the risks to exposing your client_secret are rate limit denial of service or unauthorized use of your client. I believe many developers would explicitly choose this tradeoff for the significant simplification for themselves and their users. Many of these applications must use this approach right now and large projects like SimC have not had issues with those vectors of attack.

Based on the terms and current API authentication design, many existing applications or app features will not be allowed/possible with the new API system.
As a possible solution to authentication without client_secret, EVE has the "code" grant type that only requires the client ID:

https://developers.eveonline.com/blog/article/sso-to-authenticated-calls

And/or the API terms could be loosened to allow some "at your own risk" disclosure of the client_secret.
One more thought on impact - these example applications are often the easiest kinds of applications to make and are often an entry point into software development for folks that get interested because of their love of Blizzard games.

Raising the bar in the name of security inherently trades off accessibility/usability. I worry that a lot of projects will never get off the ground if there's no easy way to get started (if the projects are even allowed by the terms)
Just curious: Wouldn't exposing the client secret be equivalent to exposing the api key now? It wouldn't actually be an additional risk, or am I missing something?

Edit: It's actually a serious question. As far as I know anonymous calls went away with the transition to Mashery. So, how is sharing an api key okay while sharing a client secret is not?
10/02/2018 11:22 AMPosted by seriallos
One more thought on impact - these example applications are often the easiest kinds of applications to make and are often an entry point into software development for folks that get interested because of their love of Blizzard games.

Raising the bar in the name of security inherently trades off accessibility/usability. I worry that a lot of projects will never get off the ground if there's no easy way to get started (if the projects are even allowed by the terms)


I just want to echo this - I have taught myself to code over the last three years specifically in order to do cool things with data about World of Warcraft. If the API worked the way it soon will when I started in 2015, I don't know if I would have been able to dip my toes in the water.
Hi Seriallos,

The decision to make OAuth our primary authentication method with our new system was made after long deliberation. That said, we are always open to discussion and even changing course for the right reasons.

We appreciate the passionate and well thought out feedback. The comments about learning to code and doing cool things with a light barrier to entry resonate.

Keep it coming... we're listening.
+1 to Seriallos's well-thought out feedback.

If I'd like to share my scripts for analyzing M+ data, now folks would no longer be able to just run the script -- they'd need to go through setting up a developer account, getting a client_secret of their own, and running the scripts. That adds a huge hurdle, even for those users who are comfortable running and downloading and running a script.

Please consider adding a way for "low-impact" users to make calls with simple parameters in the URL, without needing to maintain token state across calls.
+2 to Seriallos's well-thought out feedback.

I am only seeing negatives and am struggling to see positives with the change to the API authentication.

Personally I code for fun, my release from a very busy and stressful environment. I don't have a lot of time in the day. It now seems I'm at a juncture of scrapping 6 months of work, or having learn, oauth, understand oauth, implement it & test it, in under 3 months, when I had a go live date of my project in a months time.

The blue post mentions there was long deliberation about the decision. Why was oauth the present choice in the end, what was the tipping point?

Why will the change be made in only 3 months?
There is ONE advantage to forcing oauth calls.
A *very* frequently asked feature: guild bank API calls.

Now that all calls are identified with a proper blizzard account, user rights can be enforced, there is hope :o
That would help my guild so much...

It also lays ground for API calls conducting real actions, such as promoting/demoting people through the API (which would also help my guild A LOT) or interacting with your own inventory from a smartphone app.

However, is there is no functional upgrade to this, and if we are still limited to public readonly data, then yes, this is a useless burden :(

In the meantime, I am going to pray and grovel for these new, usefull, methods :)
10/03/2018 05:47 AMPosted by Phlogistos
Now that all calls are identified with a proper blizzard account, user rights can be enforced, there is hope :o


For the new version, all you need is a Battle.net account with an authenticator. You don't need a wow license on it or any game at all. For me there isn't much difference between a Mashery account and an additional Battle.net account made exclusively for API purposes.

Additionally, guild bank data isn't exactly a public ressource. You would need to identify as a guild member with the appropriate permissions to access it. Which means access to your wow profile, your characters and their guild memberships.

Access to player profiles - including your own - has always required using OAuth with a Battle.net account, regardless of how the developer logs into the developer panel.

So, in short: I don't think the type of developer account really matters much.
I have been creating a website for fun during these last months. It's a pure static website, so using Blizzard's API was extremely easy because I lack back-end knowledge--and I still do. I worry now that I cannot continue working freely with my project if I'm forced to have a back-end for my secret.

I understand the security Blizzard wants with these new changes they are making, but these changes will raise the bar really high for junior developers who wants to improve.
Would a JWT option be possible? I feel like this might be something that could help alleviate a lot of the complaints people have.

Seeing as how I feel like this does basically kill static only sites, since this kind of work shouldn't be done client side. (Though it isn't hard to get around with so many serverless options now available without a full backend)

Just maybe a middle ground to make everyone happy?
Unless I'm missing something... the new approach requires that you send a request to get an access token that has a relatively short expiration. Then you use that token in requests, and have to periodically generate a new token whenever it gets too old. Either that... or just send two requests for every API request: one to get a token, one to do the request.

Most APIs that I have used in the past only require your "secret key" to make requests. It's... secret, after all, so the extra work to create and manage access tokens doesn't really do anything.

The extra step to generate an access token is usually only required when you want to make an API request from a non-trusted location, like a client application or web page. In those scenarios, an access token makes sense as a way to protect your secret key.

Do you plan to add a way to avoid the extra work of dealing with access tokens for the class of "simple" applications that just want to make API requests from an already-secure location like a web server, that would never expose the secret key? As it is right now... it significantly raises the barrier to entry for programmers to manage the lifetime of access tokens on the server, without adding any additional security. (That is, unless I'm missing something about how it works now.)
1. Create a client: https://develop.battle.net/access/clients/create
2. GET https://us.battle.net/oauth/token?grant_type=client_credentials&client_id=<your client id>&client_secret=<your secret>
3. GET https://us.api.blizzard.com/wow/spell/183416?access_token=<access token>

That doesn't seem that much harder? The difference is you either have two requests per call instead of one, or you need to implement some kind of data persistence for the token.

Is there any difference in hardcoding the secret versus hardcoding the API key?

Even if you hide the API key you're just as vulnerably to rate limit attacks via your proxy.
It's certainly harder if you want to implement a good way to reuse tokens instead of generating a token for every request.

If you're fine doing two requests per API call instead of one (and you're fine with any additional latency that causes, because you have to do them one after the other), then it's not much harder.

I guess my point could be clearer stated as this: in order to do the new authorization, you really need a back-end. That's not a problem for a lot of people who already are doing this. And probably, most of these people are making their API requests from the back-end. And if you're doing that... why bother with tokens? Just send requests using a secret key.

The only time a token is really useful is if you want to send it to a client to make API requests for a bit. But... if you went through the trouble of setting up a server to generate tokens... might as well just do the API requests from the server too? In which case we're back to: the tokens aren't really necessary.

Either way it's not a "huge deal" -- won't take long to get it working for most people who have servers set up already. I'm just curious about the usage scenarios that the token-based approach is meant to facilitate.
I'm with Yellowfive, I'm having to backtrack my progression on my web app to redesign how my libraries pull data from the API as I don't want to request a token for every request, instead I'd rather use the same one until expired and if expired generate a new one... this is quite a bit of overhead to get working properly considering the old design was so much simpler.

That being said if jumping through these hoops leads to improvements to the API, such as more data being accessible to me than I'm more than willing to do it... a minor inconvenience for an improved API is worth the hassle (assuming they intend on granting us access to more data)
+100 to that seriallos guy, he brings up valid concerns that should be addressed.

I'm fine with using oath to do things like control a Nest cam or controlling smart home devices, as they're kind of personal and I'd rather not have random people all over the internet turning on my lights while I'm asleep. If I need to jump through a few hoops to make my lights turn on automatically when I open the front door after 7 PM, I understand.

I don't think the same sort of security is necessary for a read-only armory request on YoloswagginzXD who hails from the guild <YourMom Is My Epic Mount>.
10/03/2018 06:19 AMPosted by Nenedeira
10/03/2018 05:47 AMPosted by Phlogistos
Now that all calls are identified with a proper blizzard account, user rights can be enforced, there is hope :o


For the new version, all you need is a Battle.net account with an authenticator. You don't need a wow license on it or any game at all. For me there isn't much difference between a Mashery account and an additional Battle.net account made exclusively for API purposes.

Additionally, guild bank data isn't exactly a public ressource. You would need to identify as a guild member with the appropriate permissions to access it. Which means access to your wow profile, your characters and their guild memberships.

Access to player profiles - including your own - has always required using OAuth with a Battle.net account, regardless of how the developer logs into the developer panel.

So, in short: I don't think the type of developer account really matters much.


That's precisely my point. Examples :

You request guild bank info with the current secret, you could be anyone, very probably you're not in this guild or don't even have a WoW account > 403

You DO have an account, but you request guild bank info from guild X were you don't have any char > 403

You request guild bank info from guild Y were you have chars, and as your
request is OAuth authenticated, they can tell that THIS token belongs to a specific account > proper answer (with only the tabs you're allowed to see)

Now if they don't ever do a guild bank API, shame on them :o
Personally the mixed approach worked well i thought where you can pull generic data down without using oauth, but once you start wanting user specific data an OAuth token should be required. Data is part of 2 camps either generic data (not character specific) and "personal" data, which is character specific, should be behind another layer of security, until that player agrees to share it with the app via granting the correct permissions when linking their account via OAuth.

Ideally this should allow for more in depth api's behind the more "complex" OAuth system but still allow generic information to be accessed via a client secret. For example I am a SC2 API user and if I wanted ladder division info and maybe a breakdown of race by division I should only need the client secret, since that might be something I want to pull daily. But if I wanted to access the match history of a player, that player should be required to share that data via the OAuth permissions.

I hope we are able to keep some sort of hybrid system some apps will want to regularly pull generic data for historical/aggregation purposes without having to essentially spoof a dummy user.
I'm considering developing a service that would manage access tokens for users in this situation. It would work as follows:

A developer visits the service and gives me their client ID and client secret.
When the developer wants a static URL for a client credentials API call, they link to the service and provide their client ID. The service will respond to that URL with a redirect to the actual Blizzard API along with a valid token belonging to that client.

Example:
You create an app and Blizzard gives you client abcd with secret zyxw. You provide those details to the service.
You want some spreadsheet to call us.api.blizzard.com/wow/achievement/2144?locale=en_US.
You craft a URL like: https://service.example.com/abcd/us/wow/achievement/2144?locale=en_US
That would 307 redirect to https://us.api.blizzard.com/wow/achievement/2144?locale=en_US&access_token=USeeffgghh

I'm aware that handing over your client id and secret to a third party (the service) is not ideal, but it's required to keep providing valid access tokens. At least it's just one party (the service) with the secret, and not everyone (it's not in the url like the mashery api key).

Is this something anyone would be interested in using, or is giving out the secret a step too far? Honestly curious, just trying to help.

edit Ugh, I guess this runs afoul of item 2K in the terms of use. They're pretty explicit about not providing credentials to a third party. (They say "API Key" but we know what they mean.) https://www.blizzard.com/en-us/legal/a2989b50-5f16-43b1-abec-2ae17cc09dd6/blizzard-developer-api-terms-of-use

Join the Conversation

Return to Forum