16

OpenID authentication is inherently browser based. If I wanted to allow an OpenID user to authenticate against an API for use in alternative clients, is there an accepted best practice for that?

So if a user tried to log in with their OpenID into an iPhone app, for instance, how would that work? The only thing I can think of generating an API token of some sort for them and get the user to manually enter it somewhere. This approach is not user friendly.

This is the way sites like Basecamp work, but it still seems clunky to me.

Alex Wayne
  • 178,991
  • 47
  • 309
  • 337

4 Answers4

16

The problem you're seeing is not unique to OpenID. Any password-less authentication scheme can have this problem. OAuth (http://oauth.net/) is a solution that is an open standard that is quickly gaining traction on a lot of web sites. It is totally independent of how the user authenticates, so their OpenID Provider does not need to support or even be aware that your site (the "service provider" in OAuth terms) is using OAuth. Your API client can be web based or even a local application!

The process would be something like this:

Roles:

  • the user: someone who has an account with your web site.
  • service provider: your web site, which has a programmatic API that requires some credential to access.
  • consumer: the client, whether web or local application, that needs access to the service provider's API.

Flow:

  1. The user is at the consumer. He indicates he wants to access data at the service provider.
  2. The user is either redirected (if the consumer is a web site) or a browser is popped up (if the consumer is a local app) and the user sees the service provider web site.
  3. The user is either already logged into the Service Provider via a persistent cookie, or the user must first log into the Service Provider however that is done (OpenID in your case).
  4. The Service Provider then asks the user: "Consumer (some consumer) wants access to your data (or our API, or whatever). Do you want to authorize this? (yes/no)
  5. User confirms, and the browser window closes or is redirected back to the Consumer site.
  6. Via some OAuth protocol magic, the consumer now has a secret credential that it can use to access your API and access whatever user-private information you just authorized.

Obviously I can't include the whole OAuth spec here, but you can see hopefully from the above that this should solve your problem. OAuth libraries exist to make adding support for it easy.

If you happen to be using ASP.NET, I suggest http://dotnetopenid.googlecode.com/ as it recently added OAuth support (v3.0 beta 1).

Pablo Fernandez
  • 279,434
  • 135
  • 377
  • 622
Andrew Arnott
  • 80,040
  • 26
  • 132
  • 171
  • I'm looking for the same kind of explanations and your answer made a lot of improvement, but where I lack the most of informations is between the 5 and 6. Your "OAuth protocol **magic**" doesn't help me a lot :p Would it be possible that you give me (us?) more detail about where the magic happen on how the restful server is sure that an untrusted consumer has a officially logged in user ? Thank you very much! – Cyril N. Dec 21 '10 at 10:07
  • That "OAuth magic" is taken care of by a good OAuth library or reading the spec and implementing it yourself, but in short, the consumer sends a final request to the service provider with a "verifier code", in return for which the service provider sends the consumer an "access token" that it can use to sign subsequent authorized requests. – Andrew Arnott Dec 23 '10 at 05:30
4

Neither OpenID nor OAuth define how a user authenticates. They define how the consumer directs the user agent to the authentication provider, how the user agent is directed back, and how the consumer can verify the identity that the user authenticated as.

The actual method used to authenticate is out of band for both schemes.

There are differences between OpenID and OAuth, but both require that the consumer use HTTP redirects and callback URLs. They're both browser based. If your app speaks HTTP, it can do either. However, a main point is that the user is only entering credentials into a trusted app.

Karl Anderson
  • 1,798
  • 11
  • 18
2

What you want is not possible with OpenID. OpenID is based on the premise that you (the iPhone app) only want to know about your users that their OpenID-provider trusts them. They never authenticate themselves to you.

Good OpenID-providers in fact even prevent that you mediate the authentication process (as this would expose users to a possible attack - by you!): they demand that users login with them directly and refuse login-by-referral.

yungchin
  • 1,519
  • 2
  • 15
  • 17
  • This is inaccurate. OpenID is about authentication of users -- it does not preclude other authentication/authorization means for API access. This is what OAuth is all about. – Andrew Arnott Feb 17 '09 at 03:50
  • 1
    I'm just answering the question: "If I wanted to allow an OpenID user to authenticate against an API for use in alternative clients..." - this you cannot control: the provider controls the mode of interaction, not the consumer. You say that yourself in your solution too... – yungchin Feb 17 '09 at 12:04
1

See: this related question

The problem is that the openid spec has no standard provision for authentication with the provider, so the provider can elect that authentication happens via a phone call or whatever.

Hopefully more providers embrace OAuth. Alternatively you could hand code the authentication for a few of the bigger sites.

Community
  • 1
  • 1
Sam Saffron
  • 128,308
  • 78
  • 326
  • 506
  • Can I use OAuth as an OpenID consumer assuming they have setup an account with us already? or does the provider have to support it? – Alex Wayne Feb 13 '09 at 02:34
  • In OpenID there are two roles: "OpenID Provider" and "Relying Party". In OAuth there are two roles: "Service Provider" and "Consumer". It's confusing because in OpenID 1.1, the Relying Party used to be called Consumer. Anyway, the OP Provider need not support OAuth. See my own answer. – Andrew Arnott Feb 17 '09 at 03:52