Icecondor authentication

the way i am envisioning the clients sending authenticated updates to the server is:

Plan A:

  • the client(phone) generates a pub/priv key pair
  • the client sends the user to the browser with the client's configured openid and the public key in HTTP GET parameters
  • the server asks the client to do an openid login (if not already logged in).
  • if the login is successful, the public key is associated with the openid and trusted
  • updates signed with said key are accepted as authenticatied/trusted

this requires no SSL support on the server. public key encryption gives the user a big benefit in this case - a user can move all the location data from one server to another and know that the updates are authentic - its impossible for the server or service to tamper with the data as long as the private key on the phone is secure.

Plan B:

OpenID is implemented. A user status page could contain a random password. With a custom URL, the android browser can launch icecondor with the random password. The configured openid and the given password would become the HTTP basic auth to do updates to

Plan C:


  • the client gets a request token and sends the user with the token to the browser
  • the browser goes to the server and asks to login (with openid), and approve the token. this also associates the token with a user
  • the user is sent back to the client and the client exchanges a request token for an access token
  • updates include the access key/pass (a token) with each update

This flow is based on the fireeagle app 'jfireeagle'.