When the user submits her ID/password, it is parsed by the doPost() method of the servlet and
checked against a database of valid users (in the example, everybody is approved). When the
user is validated, her ID is added to her HttpSession object and she is redirected to the
servlet's doGet() method. Now future requests only need to check for the user's ID in the ses-
sion to verify that she has been properly validated.
Basic authentication is a challenge/response security model. It is based on the fact that the
client must authenticate itself with a user ID/password combination for each resource it wants
to access. A protected resource could be a directory, a servlet, or even a specific page. The
steps involved in authenticating a client are as follows:
The client makes an unauthorized request for a protected resource.
The server responds with a challenge to authenticate.
The client sends a username/password combination (separated by a colon) within a
The server decodes the string containing the user ID/password combination and looks in
its database for a match.
If the server finds a match, it grants access to the requested resource.
When you deploy your applications to a commercial level server you will need to consult the
server documentation to configure protected resources and users.
Digest authentication , like basic authentication, is based on the challenge/response model. In
fact, digest authentication was created as a direct result of basic authentication's shortcomings.
The main difference between basic and digest authentication is that the digest scheme never
sends the user's password across the network. It instead sends a digest representation of the
Currently there is no support for digest authentication.