JAX-RS with Basic Authentication. How can I safely avoid prompting for credentials on every request?
I have a JAX-RS API (running on Wildfly 8 server) which is used by a Javascript based web application. We learn as we go, so we apologize for anything that might be silly about this implementation.
We have basic authentication with a PBKDF2 based password store, but for obvious reasons we don't want the user to have to authenticate every time they click on a new navigation item in the web application.
What we are currently doing in development is to accept the credentials on the first entry and store them in a local BASE64 variable that is used in all subsequent requests (everything is over HTTPS).
The question is, for production, is this an acceptable way to handle user credentials or big no-no?
And if it's not-no, how should you do it? In the end, using sessions seems to go against the idea of RESTful web services to begin with, and Java Session Beans doesn't work too well with JAX-RS (based on what I've been able to read).
source to share
The question is, for production, is this an acceptable way to handle 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 for hanging user credentials in memory on the client side.
And if it's not-no, how should you do it?
Have you considered a token based authentication scheme? For example, OAuth2 . Typically, you have to authenticate the user once with your credentials and the server will return an access token valid for a specified period of time. Subsequent requests will use the access token, not the client's username / pw.
In the end, using sessions seems to go against the idea of RESTful web services to start with, and Java Session Beans doesn't seem to work well with JAX-RS either (based on what I was able to read).
Like everything else, there are trade-offs. IMO allowing statefulness in the business logic of your resources is a problem, but including something like a token in every request is not a big problem. Specifically when it is likely to be handled with a lower level of authentication / authorization on the client and server side.
source to share