security in rest applications

Posted by jmls on 29-Mar-2013 02:25

Ok, so I've got so far as to be able to create non-cookie expiring sessions for a rest service.

One thing that has bothered me is that in order to authenticate, you need to "log on". In a rest-style service, then means that you have to pass the user name and password in a url.

This I don't like.

I see a couple of options :

1) encrypt the username + password before sending. This would require some js on the client side, which could be reverse-engineered to work out the encryption method

2) use a https connection to (supposedly) prevent man-in-the-middle attacks. This would not prevent the browser keeping a copy of the url (complete with url parameters such as your name and password)

3) use a https connection to (supposedly) prevent man-in-the-middle attacks, with hidden fields to stop the browser keeping a copy of the url (complete with url parameters such as your name and password)

4) use a POST https connection to (supposedly) prevent man-in-the-middle attacks, with the fields sent as data so it doesn't appear in the url

Q1) : Are there any other better options

Q2): Given that there is only the choice of 1-4, which choice is the best ? I am leaning towards 4



All Replies

Posted by on 29-Mar-2013 02:28

Sorry I missed your email. I am out of the office until Tuesday 2nd April with little access to email.

Thanks, Andrew

Posted by Admin on 29-Mar-2013 04:38

Doesn't the REST Adapter support http basic authentication? At least the OE Mobile docs say that http basic authentication is supported.

That way the encoded password is passed with the encoded username in the http header.

Posted by Michael Jacobs on 29-Mar-2013 04:51


Web servers offer a number of peer reviewed authentication models that will work with the majority of HTTP clients.   You appear to be very concerned about security, so I'm assuming you are using perimiter authentication security in the web server.

So you have the well known choices of:

HTTP Basic:  (using either URL or header transport) no login-logout sessions, plus the level of obfuscation is pitiful

HTTP Digest:  no login-logout sessions, but a good level of obscuring the credentials

FORM:   login-logout sessions, but requires using HTTPS & POST to secure the credentials

SSL Client Authn:   great security - but a pain in the a** to manage and distribute client certificates

Federated 3rd party:   CAS, openid, siteminder, ...     good security but is yet another moving part to configure and maintain

My opinion: never, ever, pass user credentials in the URL.   Even with https that could expose the credentials.

My personal best choice is FORM over a HTTPS connection, just from a session management and simplicity standpoint.   But the choice is really yours depending on the value of the data.

I do not know specifically what your security requirements are, but I hope this information is of some use.

Mike Jacobs

Posted by Michael Jacobs on 29-Mar-2013 04:54

The REST adapter is tested with  HTTP BASIC and FORM authentication models, today.   The plans (such as plans go) is to also certify the HTTP Digest, SSL client, and some (?) level of Federated 3rd party over the next releases.  But this is subject to change as more infromation comes in.

Mike Jacobs

This thread is closed