12

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

mezod
  • 2,313
  • 3
  • 21
  • 31
Cyril N.
  • 38,875
  • 36
  • 142
  • 243

2 Answers2

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.
Cyril N.
  • 38,875
  • 36
  • 142
  • 243
  • I disagree. Editing a question is to provide more informations or better ordering the question. Here, I show a possible solution to my problem. Maybe not the best, but it's still an answer. – Cyril N. Dec 20 '10 at 13:14
  • OK. But why then do you ask `What do you think ?`? This poses the answer as a question... but no matter. – Félix Saparelli Dec 21 '10 at 04:16
2

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.

Félix Saparelli
  • 8,424
  • 6
  • 52
  • 67
  • I almost agree with your suggestion, but with a restriction: how the webapp can send the openid credentials to the api ? The api must ensure that these credentials are valid for a specific user, it cannot only **trust** the webapp because other application will also be able to connect to the api and could steal the identity of a user. The possible idea would be to send the response of the openid server to the API, including the assoc_handle key and then, the API server would request (again) the openid provider to check the "is_valid:true" and match the user in the db. Am I correct ? – Cyril N. Dec 20 '10 at 13:11
  • 1
    No(t entirely). You have to make the distinction between an API which acts as the unified layer between the outside world and your data(base). You could do what you suggested, but that would essentially mean to integrate an app within the API (which could be alright with you, though). As for **trust**, you could easily use public-key encryption and signing to make sure that only your (or approved) app accesses/changes the *sensitive* data. Besides, the OpenID credentials are *just* the URL -- which you assoc with the user. I suppose the user must be logged in to set this assoc, so: no problem. – Félix Saparelli Dec 21 '10 at 04:22
  • When you said "signing", you mean between what ? the app and the api ? the user and the api ? the user and the app ? I see how to identify the user for the app (with openid, like you said), but I can't see exactly how the api can trust the app about which user is using the api. You could easily create an app that connect to my api and fake the identity of a specific user in order to get their data. I need to be sure your app is respectful and which user is using it for sure, even in the api. That what I'm missing and can't understand clearly :( – Cyril N. Dec 21 '10 at 09:14
  • 1
    Well, obviously, to trust an app, you need to a) write it yourself, or b) trust the dev, read the code. In any way, it doesn't matter. All you need is to implement public-key (or other) encryption and signing between the app and the api, ensuring that a) data comes from the trusted app, and b) data can't be tampered with. By definition, you can't trust an untrusted app to do the right thing. You *could* check the openid within the api, but it would still be easy to attack if you leave any app to access the data... You've got to make sure you're talking to a trustworthy app. – Félix Saparelli Dec 21 '10 at 12:35
  • Ok I agree with you on that. The problem is that the API will be open and anyone will have the possibility to use my API. I can't be sure to talk to a trustworthy app. That where I am now :/ – Cyril N. Dec 21 '10 at 16:20
  • 1
    The answer: permissions. See above: `make sure that only your (or approved) app accesses/changes the sensitive data`. To extend on me previous comment: `You've got to make sure you're talking to a trustworthy app`... for those *sensitive* fields. Would anyone sane open 'open' access to their list of passwords, even hashed? To take upon your own statement: "The problem **solution** is that **not all of** the API will be open and anyone will have the possibility to use **the *non-sensitive* parts of** my API." – Félix Saparelli Dec 22 '10 at 08:50
  • Yep, we gonna reach the "max comments on this answer" limit :p About the problem, I asked on the #oauth irc channel, their answer was quite original : I have to use WebID, a new protocl (still in early draft mode :/) for my problem. The thing is, all the api will require a connected user, so private data so will always be shared. – Cyril N. Dec 22 '10 at 09:51
  • I'm starting to think about an other way, even it's not the perfect one. Twitter API have a web interface for their OAuth page. I think I'm gonna do the same, BUT, on this page, the user will have to first authenticate himself to THE API, and then allow application Y to access his data. If he accept, a token (à la OAuth, of course) will be share and one of this token will represent the user, for ever (or until he removes the access to this data). – Cyril N. Dec 22 '10 at 09:56
  • Regarding to the OAuth doc, http://hueniverse.com/2008/10/beginners-guide-to-oauth-part-iv-signing-requests/, it seems correct : oauth_consumer_key will represent the user, token the current session. I still have to read the oauth doc to be sure of what I'm doing. What do you think ? (I reeeaaallllyyyy appreciate all the time you took for helping me ! I deeply thanks you !) – Cyril N. Dec 22 '10 at 09:59
  • 1
    Well, open another question, and vote up/mark as correct my answer/comments... the reputation gain will help me "fund" my efforts. Closing comments: 1) there is no perfect answer; 2) WebID looks interesting; 3) ...it was great helping you! – Félix Saparelli Dec 23 '10 at 06:15
  • I marked your comment as up, since all helped me find a way. I can't see how to close comments (maybe I haven't the rights yet?) – Cyril N. Dec 23 '10 at 14:29