OAuth2 clarification

Please forgive me if these questions have been asked, I’m new to implementing OAuth2.

I’ve read a lot of posts and I think I can implement the request/token stuff fine. It doesn’t seem much harder than the curl requests I’m already making to get API (mount) data.

It’s the lower-level / non-code stuff that doesn’t seem to be discussed much, or maybe I’m just not getting it.

Do most sites/apps that use OAuth2 still have their own username/password login system, and then get the user to authenicate with Blizzard to get the access token for the day (or whatever the expiry period is)? That’s what seems logical to me, but I see references to “logging in with Battle net” which confuse me.

Once I have the access token for the user, I guess I just store it in my database so it can continue to be used until it expires, and then just request a new one once it has? Are there ever situations where these tokens expire faster than their “expires_in” data indicates?

Thanks for your help and sorry if I seem clueless with this :slight_smile: The changes to implement the new API all made sense to me as they fit in context of what I was previously doing, but this stuff less so.

That is up to you, if your app can be used without a battle net account or if you already have a login system in place it makes sense to have both. However if you have no reason to have your own login you can just use the Battle.net OAuth2 integration.

Correct, you can hold this token and use it until it expires.

In theory yes, but just for some edge cases like users revoking your app authorization from their bnet accounts or even an account getting banned. If that happens you’ll receive a 401 response.

1 Like

Hi Wain,

Happy to hopefully provide some insights into how you could implement this functionality. As a simple disclaimer, you should do your own research and investigation into best practices and merely use the below as theoretical possibilities.

It appears that warcraftmounts.com already implements an authentication system, and as such it could be more approachable to implement the addition of a “Connect with Battle.net” button to the user account page, rather than adding Battle.net as a way to signup for warcraftmounts.com. We often see this pattern utilized by community sites that wish to maintain their own user registries.

Essentially the flow would be that you require the user to signup on warcraftmounts.com using your existing registration flow, and then on the user account settings page provide them with a button “Connect with Battle.net” that will push the user into the Authorization Code Flow, which when completed will result in the retrieval of an OAuth Access Token. You can then either store this token in your database or store in the user’s session (however you have this implemented).

Once you have the token saved you can then use this token to access the Account Collections Summary API document(s) in response to user interaction, or as part of cron jobs, etc.

It is important to keep in mind that technically the token you stored could become invalid at any time, for a number of reasons. For this reason, it is important to provide sufficient error handling logic any time you attempt to utilize the token. A potential strategy for handling invalid tokens could be to require the user to “reconnect” to Battle.net anytime you fail to call the Account API with their token, which could be implemented as showing the user a message indicating that their Battle.net account needs to be reconnected, etc.

If you determine that you do not have a pressing need to keep the user’s Access Token stored other than when you are actively reading the players Account Collections Summary API document(s), then an alternative strategy to the above could be to add a “Sync Mounts with Battle.net” button, which when clicked would perform the Authorization Code Flow, retrieve the list of mounts for the user, and then store them in your database. This alternative flow would require users to re-visit your site anytime they wish to sync their mounts, which may or may not be an issue for your preferred user-flows.

Hopefully, this is helpful, and please do not hesitate to pose any further questions.


I really appreciate both your responses, thank you! :smiley:

That all makes sense and I should be able to implement this without too many hassles, I hope.