how can I authenticate a user from a web app to an API?

It seems to be a widely asked questions and after having read tons of documentations on the subject, I'm still not sure to have understood everything correctly (I assume that being dumb is a possible answer ;)).

I'm trying to build an API that will provide a service to users. The users will be connected through Facebook or any OpenId provider (I separate Facebook since their implement their own connecting system).

(I think it's a good way because I will not store the user's password and finally will have less problem in case of a similar Gawker issue.)

When a request is made from the client (web app, mobile app, whatever) to the API, an indicator must be sent with the request in order to identify which user is using the app. This is generally used via a token, defined during the Authentication.

But regarding the Authentication, I can't find any valuable example, tutorial, explanations about how to implement it correctly.

I'll (try to) explain :

In my (wonderful world of happy care bears), I structured my project in various parts :

• A RESTful API
• A web apps that will use the api. Ideally, I was thinking about making a complete html/css/js project, without any server side work (php/python/java or whatever)
• A mobile application
• An windows/mac/linux application

As far as I saw, every time someone ask how to implement a RESTful API authentication, three major answers pops out :

• The HTTP basic( + preferably SSL)/digest way
• OAuth
• OpenId

Since I will not store the user's password, the first one is out for me, but the two other leave me perplex.

But OAuth and OpenId are not the sames, one (OpenId) stand for the Authentication (that the base of the questions) where the second (OAuth) stand for the Authorization!

When Twitter implements OAuth for their API, they are not implementing an Authentication system, there are setting up a way to indicate their users that the application X want to have access to the user account (in various level of access). If the user is not currently logged in Twitter, he will first have to authenticate himself, and then authorize the current application to access his data.

So, just to clear things up, OAuth is NOT an authentication mechanism, it's a :

An open protocol to 开发者_如何学运维allow secure API authorization (source: http://oauth.net/)

Then, the only way to authenticate a user would be using OpenId. And then, the hell comes true.

If I take as an example a web application that is exclusively made of html/css/js, with no server side components, communicate with an API.

The web app must indicate to the API that the user currently using the API is mister X.

To do so, the web app show a popup containing a list of OpenId providers, asking the user to authenticate himself. The user click on one of them, get redirected (or a new popup open up) to the OpenId provider, indicate his login/pass, get authenticated by the OpenId provider, that return the success with a token (I simplified the communication).

That's great, the web app know now that the user is really mister X. But the API still have any clue !

Finally, my question is quite simple : how can I authenticate mister x through the web app to the API via OpenId and after that, how can the web app and the api keep the information that this is mister X that is currently using the web app and of course, the API.

Thank you very much for your help !

-edited format

You don't really want to login to the API using OpenID. As you said, OpenID is for Authentication, i.e. Who, while OAuth is for Authorization, i.e. am I allowed? But your structure suggest you'll be using an API as a backend and a web app as a front-end.

The best way then is to use OpenID on the web-app to authenticate the user, and then the web-app connects to the API and stores the OpenID credentials. The web-app then knows who the user is, and can provide the service. The API has nothing to do with the user, except that it stores its data.

The fundamental difference between OpenID and OAuth is its use. In your situation, you could have something like that:

--------          ---------            -------
| User | <------> |  App  | <--------> | API |
--------  OpenID  ---------   (OAuth)  -------

The User never interacts directly with the API: who would want to manually send HTTP request? (lol) Instead, the service is provided through the app, which can optionally be authorized using OAuth. However, in the case of a single app accessing the API, you can make the app <=> API connection internal and never expose it.

(If you don't want to read, the list bellow sum up the whole idea)

A possible solution (tell me if I'm wrong) would be to display the login form in the consumer (web apps, mobile apps, etc), the user click on it's provider (myopenid, google, etc) that opens a popup to do the login. The tricky part is that the return_to parameter would be set to the API, not the website

The API will then resend the check_authentication and get the is_valid:true (or not). During this step, the app would query the api to a specific url that return the state of the authentication (processing, failed, success). While it's procesing, an indicator is displayed to the user (loading gif), and if it's success/fail the result is displayed to the user.

If the api receive a is_valid:true, then it will ask informations about the user to the openid server, like email, firstname, lastname, and compare them with it's user's database. If there is a match, the api create a session between itself and the app, if the user is new, it create a new entry and then the session.

The session would be a unique token with a specific duration (maybe equal to the openid server assoc_handle duration ?)

It seems to be something possible, but I'm not an expert in security.

In order to explain things simplier, here is a little "map" :

Note: Provider is the OpenId server (that provide the informations about the authentication)

• The User go the webapp and click on the login icon of his provider (Google for ex)
• The webapp opens a popup containing the provider login page and access page, and specify a return_to to the Api
• The provider sends informations to the Api
• The Api validate these informations via the check_authentication
• If not valid, the API indicate to the webapp (that ask the api every x seconds) the failure
• If valid, the Api asks informations about the user to the provider, like email, display name, etc
• If the user exists, a session is created
• If the user is new, he's added to the database and the session is created
• The Api returns the state of the auth (in this case, success) with a token session that will be used by the web app for further requests.