4

I've got a JAX-RS API (running on a Wildfly 8 server) that's used by a Javascript-based web application. We're learning as we're going along, so apologies for anything that might be stupid about this implementation.

We've got Basic Authentication with PBKDF2-based password storage up and running, but for obvious reasons we do not want the user to have to authenticate each time they click a new navigation item in the web application.

What we're currently doing while in development is to take the credentials the first time they're entered and store them in a BASE64-encoded local variable that's used in all subsequent requests (everything goes over HTTPS).

The question is, for production, is this an acceptable way of handling user credentials, or is it a big no-no?

And if it's a no-no, how should you do it instead? After all, using sessions sort of goes against the idea of RESTful web services to begin with, and stateful Java Session Beans don't seem to work too well with JAX-RS (based on what I've been able to read).

Koeus
  • 434
  • 1
  • 6
  • 22
  • 1
    HMAC/SHA is a solid token-based model you can implement in your server code. See http://stackoverflow.com/questions/26765891/two-way-ssl-tls-authentication-in-a-rest-web-service/26766845#26766845 – lcryder Nov 25 '14 at 20:26

1 Answers1

4

The question is, for production, is this an acceptable way of handling user credentials, or is it a big no-no?

Not the end of the world if it's over HTTPS but it's not ideal to hang onto the user's credentials in memory on the client side.

And if it's a no-no, how should you do it instead?

Have you looked at some sort of token based authentication scheme? For example, OAuth2. Typically you'd have the user authenticate once with their credentials and the server would return an access token that's valid for a certain period of time. Subsequent requests would use the access token rather than the client's username/pw.

After all, using sessions sort of goes against the idea of RESTful web services to begin with, and stateful Java Session Beans don't seem to work too well with JAX-RS (based on what I've been able to read).

Like anything else, there are tradeoffs to be made. IMO, letting statefulness creep into the business logic of your resources is an issue but including something like a token in each request isn't a big deal. Particularly when it's probably going to be handled by lower level authentication/authorization code on both the client and server side.

Community
  • 1
  • 1
John R
  • 2,066
  • 1
  • 11
  • 17
  • The only thing I've heard of OAuth2 is that it is supposed to be incredibly complicated to implement in a secure manner, but I haven't looked in to it too deeply myself. I'd like to keep things simple, what about doing something like [a custom header to keep a randomly generated session ID](http://stackoverflow.com/questions/12086041/basic-authentication-with-a-guid-token-for-rest-api-instead-of-username-password)? – Koeus Nov 25 '14 at 16:17
  • Yes, it is a rather complicated spec. There are several different "flows" defined by the spec, each addressing a separate use. What you're interested in is the [Resource Owner Password Credentials Grant](https://tools.ietf.org/html/rfc6749#section-4.3). Basically you make a POST and get back an access token. If you do use OAuth2, I highly recommend that you use the OAuth2 support provided by your JAX-RS implementation rather than attempt to implement it yourself. – John R Nov 25 '14 at 16:26