DSS: Facilitating API authentication for desktop apps

Question

desktop-stack-serv

Auth server for desktop applications authenticating with the Stack Exchange API.

What?

The Stack Exchange API enables applications to get data about Stack Exchange sites or users. It also supports write actions such as creating posts or comments, flagging, voting, and so on. To do the latter, applications must authenticate to get a write token for a user.

For server-based applications, this is trivial. However, for client-based applications, it's not so easy - either the application's maintainers must host a web server of their own, or must ask users to go through processes that less technical users may find difficult.

This project solves that issue by making an open-source token server available. Instead of hosting their own web server, project maintainers can use this server, which is available at https://auth.artofcode.co.uk/.

Source available on GitHub.

How?

Very simple.

• When creating your app on Stack Apps, enter artofcode.co.uk as the OAuth domain, and enable client-side (implicit) authentication flow.
• Follow the API's documentation for using the implicit flow. You should use a value of https://auth.artofcode.co.uk/auth/redirect for the redirect_uri parameter, and you should generate a UUID or equivalent random token (a SHA256 hash of a random value, for example). You should pass this to the API as the state parameter.
• The user authorizes your app, and is redirected to redirect_uri. DSS stores the access token against the state value.
• The user returns to your app, and informs you that they have completed authentication. Your app should now make a HTTP GET request to https://auth.artofcode.co.uk/auth/token?key=<uuid>, where the value of the key parameter is the UUID or random token you generated earlier. A JSON object containing one key, access_token, will be returned.

Notes

• Make sure the random token you generate for the state parameter is URL-safe.
• Don't generate a token based on the current time; that opens the door for app collisions, which could be bad.
• If there's no token stored when you call /auth/token, you'll get a JSON object containing error_name and error_message parameters. You'll also get this if you don't pass a key parameter.

Answer 1

I think, in the name of being cooperative, anybody using this should consider generating a key that is prefixed by their app's client ID, e.g. if your app ID is 3456:

3456-<uuid>

Sticking to something like this will prevent key collisions.

Also I have an idea for how to implement this in DSS, and I might get a chance to make a PR for it some day, but the idea is:

• Add an optional app ID parameter to /auth/redirect e.g.:

  https://auth.artofcode.co.uk/auth/redirect?appid=3456
  

  Note that this can be passed URL encoded to the redirect_uri parameter, e.g.:

  ?redirect_uri=https%3A%2F%2Fauth.artofcode.co.uk%2Fauth%2Fredirect%3Fappid%3D3456
  

• So you do that and also pass your random uuid to state.

• DSS maintains accessTokens[appid][state].

• And then you request the token from:

  https://auth.artofcode.co.uk/auth/token?appid=<appid>&key=<uuid>
  

This way DSS encourages implicit separation of keyspaces. For laziness/compatibility reasons, appid is optional at all points and just uses a global keyspace if not specified (internally the DDS implementation can just pretend it's 0 or something if it's missing).

This should work, and if nobody else does it or nobody has a better idea, one of these days (probably not soon) I'll submit a PR for it.