GitHub API Issue - Creating a Public Key

Question

This is extremely strange (and perhaps insecure behavior) so please bear with me as I try and explain this. I've been debugging this for hours and can't figure out why Github API is acting this way to my RESTful API requests.

I am authenticating my app with Github oAuth API. When a user successfully authenticates their github account, I get an access_token for the user based on the scopes requested... No problem, standard oAuth behavior (https://developer.github.com/v3/oauth/#web-application-flow).

Then, with every subsequent API call, I attach the access token to the HTTP Authorization header like so:

Authorization: 'token abcdefghijklmnopqrstuvwxyz123456789abcde'

The action I'm trying to perform with the access_token is adding a Public Key to the user's account, and everything seems to be just fine: https://developer.github.com/v3/users/keys/#create-a-public-key

Now, the weirdness happens when doing this with 2 user accounts. If I have 2 users, let's say, Alice and Bob.

Alice logs into the app with github, is given an access_token 'aaa' and my app is able to successfully add a public key to her account by using the 'aaa' access_token in the Authorization header.

I log out of the app as Alice and log in as Bob using Bob's github credentials. The auth is successful and Github provides Bob an access_token 'bbb'. However, when trying to add the public key to Bob's account I get a "key is already in use" error, even though Bob does not have ANY public keys in his account.

However, by using Bob's access_token 'bbb' for other API requests, such as listing private repositories and organizations, Github returns Bob's data. It seems that when creating a public key in his account, Github is still associating Bob's access_token 'bbb' with Alice's public keys.

What's even stranger is that I have verified this because once I delete the public key from Alice's account, I am able to successfully login with Bob and add the public key to Bob's account, not Alice's!

I have tested this behavior in the same browser, in two different browsers on the same computer and on two different computers in two separate geographical regions of the country with the same result.

I am assuming that the access_token provided by Github will properly associate the user account that actions are to be performed against. Particularly with POST and DELETE requests where the username is not indicated in the URL like with most GET requests.

I'm sure I'm missing something, but if someone can provide some insight it'd be greatly appreciated, thanks!

Answer 1

This isn't related to tokens or the API at all -- it's related to SSH keys. You can't add the same SSH key to two different GitHub accounts. How would that even work? Imagine you add the same key to Alice and Bob, and then you want to use that key to perform a git push. And lets say that the push is targeting a repository for which Alice has push permission but Bob doesn't. Would you allow the push or not? You couldn't make that decision because you wouldn't be able to determine which permissions to use for authorizing the call -- Alice's or Bob's -- because the key isn't uniquely associated with a single user.

SSH keys need to be unique for users (if they are user-level keys) or repositories (if they are repository-level keys, aka deploy keys), so you need to generate a new SSH key for each user you have and not add the same one to all of your users' accounts. The error message you're getting back from the API is telling you that the key is already added to a different account. You'd see the same message if you tried adding it to that account via the Web UI.

Telling you that the key has already been added to a different account isn't really insecure because those are public keys, not private keys that you are adding to GitHub. Public keys are public, so anyone can determine what the public keys are for user X and try to add the public key from X. They'd then observe the same error you observed, but that wouldn't reduce the security of user X because the private key isn't exposed by all of this.