For a J2EE Container, authentication comes down to this: ask for a user name and password, then verify that they match.

The first time an un-authenticated user asks for a constrained resource, the Container will automatically start the authentication process. There are four types of authentication the Container can provide, and the main difference between them is, “How securely is the name and password info transmitted?”

The FOUR authentication types

BASIC authentication transmits the login information in an encoded (not encrypted) form. That might sound secure, but you probably already know that since the encoding scheme (base64) is really well known, BASIC provides very weak security.

DIGEST authentication transmits the login information in a more secure way, but because the encryption mechanism isn’t widely used, J2EE containers aren’t required to support it. For more info on DIGEST authentication, check out the IETF RFC 2617 (www.ietf.org/rfc/rfc2617.txt).

CLIENT-CERT authentication transmits the login information in an extremely secure form, using Public Key Certificates (PKC). The downside to this mechanism is that your clients need to have a certificate before they can login to your system. It’s fairly rare for consumers to have a certificate, so CLIENT-CERT authentication is used mainly in business to business scenarios.

The three types above—BASIC, DIGEST, and CLIEN-CERT—all use the browser’s standard pop-up form for inputting the name and password. But the fourth type, FORM, is different.

FORM authentication lets you create your own custom login form out of anything that’s legal HTML. But... of all four types, the form-based info is transmitted in the least secure way. The username and password are sent back in the HTTP request, with no encryption.