Koeus
Koeus

Reputation: 444

JAX-RS with Basic Authentication - How to safely avoid asking for credentials on each request?

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).

Upvotes: 4

Views: 895

Answers (1)

John R
John R

Reputation: 2096

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.

Upvotes: 4

Related Questions