0

I'm writing an Android app that will require folks to identify themselves. We figured that the best course of action is to NOT have folks register with our server since practically everybody has an account somewhere else with a major service (Google, Twitter, Facebook, Yahoo! for example).

The REST API is being built around CakePHP. This in itself isn't a sticking point for what I need, but the issue is more on the Android app along with its communication to our API. Essentially what I'd like to see is a user with X number of devices having the ability to login to a service they already have access to.

This identity would then be known by our server as an identity for that user. My app would then need a way to tell our API that "I am John Doe from service example.com, and here's proof". The servers would also accept a new device for the same identity and tie it in to that user.

I am stuck on some issues here:

  • OpenID seems to be the way to go (though I'm not sure if Twitter supports OpenID). But how can I do OpenID from my device? I don't need somebody to point me to OpenID for Java. This is NOT 100% of the answer I am looking for. Where is the website going to redirect to?
  • What will the authentication piece be like between my webserver and Android app? I'm not logging in. I'm using an OpenID. Should I just take some/all of the OpenID information and pass it to the webserver for storage, and then pass it again to check against for every API call?
tomwardiii
  • 61
  • 2

1 Answers1

0

Twitter not only does OpenID, but they also have a dedicated page talking about what the flow is and what you need to store. Google has a similar page for their login. The OpenID login flows are (for the most part) OAuth2.

Mark S.
  • 3,849
  • 4
  • 20
  • 22
  • No, they are different. This example isn't OpenID this is OAuth. They work in similar ways but they do different things. OpenID is like your license and registration of your car, whereas OAuth is a key to the car. They're only similar in that they are using authentication credentials verified by a 3rd party server. – tomwardiii Aug 23 '12 at 19:41
  • The Twitter OpenID flow returns the OAuth Token and Secret. The Google OpenID flow returns the OAuth Token and Secret. They're used for different purposes, but they're starting to merge into one protocol – Mark S. Aug 23 '12 at 19:48
  • No, there's a specific OpenID/OAuth pattern for things like Google. The page you linked to doesn't seem to follow the OpenID API standards and isn't related to OpenID. It's possible I can still look into OAuth for things like Twitter, but then that brings around the question of what I should store on the server. – Jouva Moufette Aug 23 '12 at 23:04
  • in case you were wondering, the difference between openid and oauth is given here: http://stackoverflow.com/questions/1087031/whats-the-difference-between-openid-and-oauth – mulllhausen Aug 24 '12 at 01:57
  • From the Google webpage I linked to: "The Google endpoints described here align with the OpenID Connect specification, which at the time of this writing, is in early draft stage. For reference, the OpenID Connect specification is very similar to the OAuth 2.0 protocol. These Google endpoints will update as the specification matures." – Mark S. Aug 24 '12 at 02:25
  • @MarkS. That's OpenID Connect which is an extension of OpenID. If you read what you pasted properly, you'd see it means that the way they have their OAuth 2 spec setup is in a way that would be ready for them to implement OpenID Connect without the API users needing to change their end point or parameters or such. It also says it's in an early draft stage, meaning it's NOT ready. So it's not implemented at all. Everything you've linked thus far is OAuth related, not OpenID. I appreciate your enthusiasm for answering me, but **please** stop wasting my time by giving me incorrect answers. – tomwardiii Aug 24 '12 at 14:16