Question

I am working on a REST system, and am about to start developing a way in which a user authenticates in order to use the service. After researching hashing methods, I have read WikiPedia - Basic Authentication

However I have some questions about implementation. If I understand correctly, the username and password will be encoded into base 64 and sent in to the server. This is where my confusion lies.

Once the server receives such a request, I assume I must decide the base64 and check it against the hash. However, once this is done, I don't understand what must be done to verify the user for future requests.

Must I check this base64 sent on every communication? I don't want to save the base64 on the server to prevent against having to check the password every time because this would defeat the purpose of only having hashed passwords. In addition, my service is SSL only, so is there any down side to passing in the username and password as a parameter in the rest request as a means of authentication, instead of in http headers?

Was it helpful?

Solution

Basic auth is just a standard way to send username and password from a client via HTTP to a server. It doesn't define whether to use underlying SSL, or whether this is the first of several calls.

What I want to say: you can decide.

However, REST is meant to be stateless, thus you should rather send it every time you connect to the server, instead of creating some kind of session.

The advantage of basic auth over REST-params is, that the former is part of almost every web-framework (e.g. Java EE, Spring Security). While the latter will add the extra params to all your requests and needing you to check it every time yourself.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top