linux poison RSS
linux poison Email

How authentication work between web server and Browser

When a particular resource has been protected using basic authentication, Apache sends a 401 Authentication Required header with the response to the request, in order to notify the client that user credentials must be supplied in order for the resource to be returned as requested.

Upon receiving a 401 response header, the client’s browser, if it supports basic authentication, will ask the user to supply a username and password to be sent to the server. If you are using a graphical browser, such as Netscape or Internet Explorer, what you will see is a box which pops up and gives you a place to type in your username and password, to be sent back to the server. If the username is in the approved list, and if the password supplied is correct, the resource will be returned to the client.

Because the HTTP protocol is stateless, each request will be treated in the same way, even though they are from the same client. That is, every resource which is requested from the server will have to supply authentication credentials over again in order to receive the resource.

Fortunately, the browser takes care of the details here, so that you only have to type in your username and password one time per browser session - that is, you might have to type it in again the next time you open up your browser and visit the same web site.

Along with the 401 response, certain other information will be passed back to the client. In particular, it sends a name which is associated with the protected area of the web site. This is called the realm, or just the authentication name. The client browser caches the username and password that you supplied, and stores it along with the authentication realm, so that if other resources are requested from the same realm, the same username and password can be returned to authenticate that request without requiring the user to type them in again. This caching is usually just for the current browser session, but some browsers allow you to store them permanently, so that you never have to type in your password again.

The authentication name, or realm, will appear in the pop-up box, in order to identify what the username and password are being requested for.


Unknown said...

i love this article of how authentication work between web server and browser. i learned a lot and i learn how is the process.

site said...

I'm trying to connect to a web server requiring mutual authentication via a browser (Google Chrome in my case). For this, I have created a pkcs12 key with openssl. and imported in to the browser. Also I have imported the public cert of the key that I imported to the browser, in to the server's trust store. When I try to access the management console through the browser, I get a error at the server side:

ERROR: com.idoox.wsdl.xml.WSDLReaderImpl - Received fatal alert: bad_certificate
ERROR: - Systinet Server Admin Console:
EXCEPTION: Error obtaining WSDL definition from https://:6443/PingService/
org.systinet.wasp.webservice.LookupException: Error obtaining WSDL definition from https://:6443/PingService/
at com.systinet.wasp.webservice.ServiceClientImpl.lookup(
....... contd.
Please note that I have not posted the complete stack traces

I had a look at the ssl logs using in the server side, and I noticed the following errors:

JsseListenerImpl-2, SEND TLSv1 ALERT: fatal, description = bad_certificate
JsseListenerImpl-2, WRITE: TLSv1 Alert, length = 2
JsseListenerImpl-1, WRITE: TLSv1 Change Cipher Spec, length = 1
JsseListenerImpl-2, called closeSocket()
*** Finished
verify_data: { 39, 97, 120, 248, JsseListenerImpl-2, **handling exception: null cert chain**
174, 77, JsseListenerImpl-2, called close()
114, JsseListenerImpl-2, called closeInternal(true)
200, JsseListenerImpl-2, called close()
255, JsseListenerImpl-2, called closeInternal(true)
51, 240, 129 }..........
Good day~ Bob

Post a Comment

Related Posts with Thumbnails