CODEWITHSUNDEEP
jqueryhtmlwcfrest
Jeffrey Kevin Pry
Jeffrey Kevin Pry

Reputation: 3296

Securing Rest Endpoints

I have a REST endpoint implemented using WCF. All data back and forth is encrypted with SSL. I am developing a web front end (that uses just plain HTML and Javascript) to expose functionality of the service. However, I am a little confused on how to handle authentication.

According to Fielding 5.1.3: "...such that each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client."

Naturally, I want to have a login page for the application that will allow the user to enter their credentials and then the REST service will "authenticate" them and make sure they are valid. However, if I keep the REST services stateless, where do I store the authentication information on the client side? I have looked into solutions such as OAuth 1.0 and the 2.0 draft but it doesn't seem that this is what I need.

Mainly, my question is, if a user "authenticates successfully" how can I maintain this state in the client side?

Here is the flow of data:

User Views Login Page ---> Browser submits AJAX request to REST service and waits for reply ---> the server returns valid ---> the REST services are now unlocked and ready to use for the current "session" in the scope of the user that is currently logged in.

Upvotes: 1

Views: 538

Answers (3)

bloudraak
bloudraak

Reputation: 6002

I am in a similar situation and use OAuth 2.0. I have several domains, namely one to manage accounts, one for developers, one for the API and one for the application. I allow other third parties to use the REST API. It is rather straightforward with dotnetopenauth 4.

No state is maintained on the REST server per se. Any web application requests a "token" from the accounts website which in turn authenticates the user using openid 2.0. The "token" to the REST server is verified every call. State is maintained by the web application in that the token is stored in the database (for persistance) and session (for caching). This works great to impersonate a user from other applications without them having to reveal any "secrets" to the application. The protocol deals with expiry and revocation of tokens. The application acts as a proxy for browser requests, including AJAX. This simplifies the javascript on the client in terms of security.

An alternative would be to use the Amazon way where you sign a request with a secret that the REST service has. For each request, you perform the exact same algorithm to sign the request and if it is the same you know the request is legitimate. While this is simpler than OAuth 2.0 you'll need to invent your own scheme to deal with that secret being revoked.

Upvotes: 1

devstruck
devstruck

Reputation: 1507

The easiest solution I see would be to place your login credentials in an encrypted cookie. I have seen some debate upon whether cookies can be part of RESTful services, and I can understand the arguments that cookies don't belong in REST, but this is certainly the most RESTful way to use a cookie. The readiest solution outside of that I can see would be to have some sort of login hash that you pass into (and, presumably return) with each call).

Upvotes: 1

Oved D
Oved D

Reputation: 7442

When the user successfully logs in, you should generate an authentication token, and save that in a cookie for the user. That authentication token is mapped in the db to the user's username.

With every request the user sends to the rest service, grab that token from the cookie and send it either in a header or in the body of the request. The service would look up that token and match it up with the username.

You can use the The Microsoft Enterprise Library Security Application Block to generate tokens.

Upvotes: 1

Related Questions