3

I read this article on soundcloud's api:
http://backstage.soundcloud.com/2011/08/soundcloud-mobile-proxies/
It talks about consuming your own API. What I don't understand is how they avoid giving away the secret key. If you normally give the secret key to a developer who is going to use it in his API how do you give the secret key to yourself and avoid divulging it without transferring it over the wire? I am assuming there is a new secret key for each user. Otherwise each user would have the same secret key and a new public key and I am not sure if that would work.

I am not talking about developers. I am talking about users like us are to Stack Exchange (actual users of the app itself). My app will be consuming it's own API. Each user that signs up for the app (I assume) would get a private and public key. Each call to the API would need to (potentially) authenticate with a public and private key. If in this situation the user is a regular user of the app, how does one get the private key to the user. Or is this not the best way to do this?

Arseni Mourzenko
  • 134,780
  • 31
  • 343
  • 513
user974407
  • 211
  • 2
  • 6

2 Answers2

3

The cryptographically secure way is for each client to generate its own secret key, and to generate a key signing request to the the server. The server then reviews the incoming requests and decides if it wishes to sign that key.

The API service then works like this. It requires client authentication using certificates. If the certificate is signed by the servers authority, and is not on the blocked list then the connection is accepted, otherwise the connection is rejected.

The end result, as long as you only sign a signing request when you are sure of its source then you can be sure that the client is who it claims to be (or its private key has been compromised) By maintaining a blocked list on the server, validly signed certificates can still be failed to be allowed access.

Michael Shaw
  • 9,915
  • 1
  • 23
  • 36
1

I would guess the same way as https works now: you don't publicise the private key, only the public key. Only your internal code will confirm the public key against the private key.

Mark Hurd
  • 343
  • 1
  • 3
  • 12