Results 1 to 6 of 6

Thread: Verifying a player account using API token

  1. #1
    Kitty
    Join Date
    Apr 2015
    Location
    Florida, USA
    Posts
    39

    Lightbulb Verifying a player account using API token

    I have written a bot for Discord that relies heavily on the Clash of Clans API to keep track of player data and which organizes users in the Discord server based on their membership and rank in our family of clans. Currently, account "linking" (telling my bot which Discord user is which player account) is a manual process. This is not ideal, because of the lack of automation and increased possibility for human error. I would really like to use the API token which is provided in-game and used by a few websites to verify the ownership of a player account. However, the Developer Portal does not include any endpoints to support this.

    Please add the user API token verification endpoint to the Developer Portal/API documentation. Thank you!

    Related: https://forum.supercell.com/showthre...4460-API-Token

    Darian responded to this other thread and said "Once we have the World Championships registration site up and running, the token will be able to be used by API developers." However that was over a year ago and no more information has been posted about the API token since then.
    Last edited by eslindsey; February 6th, 2020 at 04:05 PM.

  2. #2
    Forum Champion JusMe's Avatar
    Join Date
    Feb 2017
    Location
    amongst the stars
    Posts
    5,544
    This has been asked for a long time now ... and yes, apart from that answer from Darian I haven't seen anything either. We also have been waiting for it ... we'd like to do some stuff with our website and maybe discord too... quite a few things on hold

  3. #3
    Fresh Spawn
    Join Date
    Dec 2013
    Posts
    8
    This is a complete guess, but I think the reason they haven't released this feature for the general public is because it's not a good validation method, because tokens can be reused by services. For example, I could run a web service that asks users for their API Token ingame, and then take that token and pretend to be that user to Clash of Stats, registering or resetting their account. That's very bad for security.

    Independent of this API Token button, they seem to have made an OAuth flow for SCID, for their Creators program, visible at https://creators.supercell.com/en/register that looks like it was made with public access in mind, if you look at the JWT issued by the button itself, which has scope "identity.relay_email" and aud "scid:oauth:login-1". I'm personally hoping they make this public, as it's more standard and more secure than the in-app API Token button.
    Last edited by kuilin; February 14th, 2020 at 08:27 PM. Reason: Removed random emoji

  4. #4
    Yes, the OAuth option seems more suitable for use by the general community. Hopefully this is something we get access to soon.
    Clash Ninja - Upgrade Tracker and Guides
    https://www.clash.ninja - Forum Thread

  5. #5
    You are wrong.
    The token work one time. When you click in game to get the token, you got different value on the next click.
    The token is used to ensure you are the owner, after your enter your token on Clash of Stats, the token expires. Clash of Stats not reuse the token because it store the a link between your account and your player tag in her database.

    There is no real reason for SuperCell for keep token documentation in private.
    Last edited by SoldatBourrin; February 17th, 2020 at 11:01 AM.

  6. #6
    Fresh Spawn
    Join Date
    Dec 2013
    Posts
    8
    Quote Originally Posted by SoldatBourrin View Post
    You are wrong.
    The token work one time.
    That's not what I mean at all. Yes, tokens can't be reused in the sense that it might be submitted twice to Supercell, but they can be reused from a cryptographic perspective, in the sense that the user uses her token to authenticate to your service, and then in turn your service can reuse the token as authentication, and pretend to be the user to another service. The token is still submitted to Supercell only once, but by the service being attacked/proxied, in this case.

    For example, say I set up a service "Clash of Bats", that allows users to upload cute screenshots of ingame bats. When verifying a user's account, I can reasonably ask the user for a token, right? But then, when the user gives my service their token, instead of submitting the token to Supercell, my service instead then makes a web request to Clash of Stats with the token that the user just passed to me, claiming that I am that user in their login flow. In this way, I automatically take over their Clash of Stats account, which should not have been possible.

    The way OAUTH prevents this is to define a callback URL in the flow that's transparent to the user. So, the user is redirected to a login page that's controlled by Supercell, with a parameter that redirects back to the service that originated the authentication request. In this way, if I wanted to pretend to be Clash of Stats at any part of the flow, I could, but in the end the service that controls the page the user ends on has to be Clash of Stats, which means the exercise was pointless anyways and I still can't get that information.

    Arguably, Supercell has already messed up from a strict security perspective, by offering authentication to Clash of Stats without publicly posting a list of services that it has given this feature to beta test, because I can currently do all of the above even when the API feature is private, because my hypothetical users have no way of knowing or verifying whether I was trusted by Supercell to use this feature... but eh, I suppose all people involved are all aware of that, and there's nothing significant anyone can do with a compromised Clash of Stats account anyways so, I'm sure nobody cares.
    Last edited by kuilin; February 18th, 2020 at 04:42 PM.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •