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

Question

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 th

Answer 1

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.

Answer 2

(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.