Basic question on RESTful authentication

[Thamizh Arasu]

Hi,

I have a very basic question on RESTful authentication. I have started writing one RESTful service for my business need. I read in one article that, in order to scale easily we should NOT be having any sticky sessions. In that case i dont know how to keep the authentication information.

When I request the server for the first time I could get the user name and password. Based on the I can authenticate the user. Then I can return back the auth token to the client. From then the client can send the auth token to the server in order to maintain he is already authenticated. But in the server side how the authentication will be maintained? Do we need to keep the authenticated information in HttpSession?

Thanks,

Tham

[Radhakrishna Kalyan]

Hi,

Since the client will always send the Auth Token then you either can write a Servlet filter to authenticate the validity of the token or if you are using oAuth then you can use Spring OAuth or any other Oauth library.

Personally I think maintaining authentication information would be over head on the server.

Please comment if my opinion is either not what you expected or if I am wrong somewhere.

Kalyan

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Thanks and Regards
N Radhakrishna Kalyan

P:  +46 768 800 824
http://about.me/nrkkalyan

[Masees Skenderian]

The way we have setup our API, it generates a Token in the DB. So any api server that gets the request can check the token against the DB to see if its still valid.

[Thamizh Arasu]

Hi Masees,

In that case will you keep the user name and password against the token in the db? Otherwise how the API token will be identified against a particular user?

THanks,

Tham

--
You received this message because you are subscribed to a topic in the Google Groups "API Craft" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/api-craft/5hn-CXk7Eag/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to api-craft+...@googlegroups.com.

Visit this group at http://groups.google.com/group/api-craft?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Thanks,
Thamizharsu S

[Jeff Schmidt]

Tham,

Depending on your application, HTTP Basic authentication can work. That is, require the client to pre-emptively include their credentials in the Authorization header for each request. You application will authenticate each time, and you process the request.  Any API server can handle it, there is no state. Make sure you configure your container to not create a new HTTP session for each successful authentication.

That's all good if your client has direct access to the credentials, and this is all done over HTTPS.  Making use of some kind of token has become more common to support delegated authorization etc. whereby third party applications can be authorized to access your resources on your behalf, but you certainly don't want to provide them with your account credentials and full access to everything.  OAuth 2.0 has the momentum here.

So, given a token, it must be presented for each API request made, typically using the Authorization header or a request parameter.  Depending on your application, this token could be relatively ephemeral or long lived; e.g. say I authorized your app to access my LinkedIn account for 30 days, or until I revoke it.  So, these tokens must be persisted and attributed to the proper user of your application (via some kind of user ID, not their user name and password).  With all of your app servers having access to this information, a request can be handled by any one of them, and not be dependent on any lingering session state.

In my case, we have an application that is invoked by tenant applications, or by various user agents on the tenant's behalf.  I say this because there is no end user data maintained by our application, only our own canonical content as well as tenant specific content.  So, the tenant application obtains the OAuth bearer token on behalf of any client they 'deem worthy' to be able to access our APIs. We provide widgets they can embed in their pages, and they make this token available to them. Using JSONP, these widgets invoke our APIs with the tenant provided token. The tenant application obtains the tokens using our OAuth authorization server.

If your application is Java based, Kalyan's suggestion for using Spring Security OAuth is a good one. That's what we use. :)  When a token is created by the tenant application, it is recorded in a database, and attributed to the tenant. That token is then returned to the tenant and eventually our application sees it again when the user agent is invoking our APIs via JSONP. If the token is still valid (has not expired or been kicked out due to suspected abuse), then the token is used to identify the tenant that provided it. That allows us to attribute usage to the proper tenant, determine associated roles (representing features, depth of canonical data access etc.), as well as access the correct tenant content in the course of satisfying the request.

Depending on the nature of your application/data, you may require HTTPs to help prevent token hijacking, or just protect the data being returned etc.

Hope this helps. Good luck!

Jeff