HTTP Authentication and http Authentication
Refer to blog: HTTP protocol details
HTTP Request Header: Authorization
HTTP Response Header: WWW-Authenticate
HTTP authentication is based on the query/response (challenge/response) Authentication mode.
I. Basic CertificationBasic authentication (authentication method proposed by HTTP1.0)
Basic Authentication steps:
Note:
Advantages:
Disadvantages:
Example:
In this example, the server accepts the authentication screen and returns the page. If the user creden are invalid or invalid, the server may return the 401 response code again. The client can prompt the user to enter the password again.
Note: The client may not require user interaction. The authentication message header is sent in the first request.
Client request(No authentication information ):
GET/private/index.html HTTP/1.0
Host: localhost
(Follow a line feed and press enter (CR) to add a line feed (LF) |
Server Response:
HTTP/1.0 401 Authorization Required
Server: HTTPd/1.0
Date: Sat, 27 Nov 2004 10:18:15 GMT
WWW-Authenticate: Basic realm = "Secure Area"
Content-Type: text/html
Content-Length: 311 <! Doctype html public "-// W3C // dtd html 4.01 Transitional // EN"
Http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd>
<HTML>
<HEAD>
<TITLE> Error </TITLE>
<META HTTP-EQUIV = "Content-Type" CONTENT = "text/html; charset = ISO-8859-1">
</HEAD>
<BODY> <H1> 401 Unauthorized. </H1> </BODY>
</HTML> |
Client Requests(Username "Aladdin", password, password "open sesame "):
GET/private/index.html HTTP/1.0
Host: localhost
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ =
(Follow a blank line, as described above) |
Server Response:
HTTP/1.0 200 OK
Server: HTTPd/1.0
Date: Sat, 27 Nov 2004 10:19:07 GMT
Content-Type: text/html
Content-Length: 10476
(Followed by an empty line, followed by the HTML text on the page for creden ). |
7. HTTP OAuth Authentication(For details, see OAuth 2.0)
Running Process(A) After the user opens the client, the client requires the user (Resource Owner) to authorize.
(B) The user agrees to authorize the client.
(C) The client uses the authorization obtained in the previous step to apply for a token from the authentication server.
(D) after the authentication server authenticates the client, it confirms the correctness and agrees to issue a token.
(E) The client uses the token to apply to the resource server (the server where the service provider (Google) stores the resources generated by the user) to obtain the resources.
(F) The resource server confirms that the token is correct and agrees to open the resource to the client.
Ii. Digest AuthenticationDigest authentication (alternative to Basic authentication proposed by HTTP1.1)
In HTTP digest authentication, MD5 encryption is used to achieve "irreversible". That is to say, it is quite difficult to determine the original input when the output is known. If the password itself is too simple, you may try all possible input to find the corresponding output (brute-force attack), or even use a dictionary or a proper search table to speed up the search.
Example and description
Note: The client may already have a user name and password, so you do not need to be prompted, such as the one previously stored in the browser.
Client request (no authentication ):
GET/dir/index.html HTTP/1.0
Host: localhost
(Follow a new line in the form of a carriage return and a line feed) |
Server Response:
HTTP/1.0 401 Unauthorized
Server: HTTPd/0.9
Date: Sun, 10 Apr 2005 20:26:47 GMT
WWW-Authenticate: Digest realm = "testrealm@host.com", // authentication domain
Qop = "auth, auth-int", // protection quality
Nonce = "dcd98b7102dd2f0e8b11d0f600bfb0c093", // server password Random Number
Opaque = "5ccc069c403ebaf9f0171e9517f40e41"
Content-Type: text/html
Content-Length: 311 <! Doctype html public "-// W3C // dtd html 4.01 Transitional // EN"
Http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd>
<HTML>
<HEAD>
<TITLE> Error </TITLE>
<META HTTP-EQUIV = "Content-Type" CONTENT = "text/html; charset = ISO-8859-1">
</HEAD>
<BODY> <H1> 401 Unauthorized. </H1> </BODY>
</HTML> |
Client request (username "Mufasa", password "Circle Of Life "):
GET/dir/index.html HTTP/1.0
Host: localhost
Authorization: Digest username = "Mufasa ",
Realm = "testrealm@host.com", // authentication domain
Nonce = "dcd98b7102dd2f0e8b11d0f600bfb0c093", // server password Random Number
Uri = "/dir/index.html", // URI Summary
Qop = auth, // protection quality
Nc = 00000001, // request count
Cnonce = "0a4f113b", // random number of client passwords
Response= "6629fae49393a05369978507c4ef1 ",
Opaque = "5ccc069c403ebaf9f0171e9517f40e41"
(Follow a new line in the form described above ). |
Server Response:
HTTP/1.0 200 OK
Server: HTTPd/0.9
Date: Sun, 10 Apr 2005 20:27:03 GMT
Content-Type: text/html
Content-Length: 7984
(A blank line followed by a restricted HTML page requested) |
3. response Calculation
Because the server has the same information as the client, the server can perform the same calculation to verify the correctness of the response value submitted by the client.
In the example given above, the result is calculated as follows.(MD5 () indicates the function used to calculate the MD5 hash value. "\" indicates the next line. quotation marks are not used for calculation)
HA1 = MD5 ("Mufasa: testrealm@host.com: Circle Of Life ")
= 939e7578ed9e3c518a452acee763bce9
HA2 = MD5 ("GET:/dir/index.html ")
= 39aff3a2bab6126f332b942af96d3366
Response = MD5 ("939e7578ed9e3c518a452acee763bce9 :\
Dcd98b7102dd2f0e8b11d0f600bfb0c093 :\
00000001: 0a4f113b: auth :\
39aff3a2bab6126f332b942af96d3366 ")
= 6629fae49393a05369978507c4ef1
At this time, the client can submit a new request and reuse the server password random number (nonce) (the server only issues a new nonce after each "401" response ), however, the random number (cnonce) of the new client password is provided ). In subsequent requests, the hexadecimal request counter (nc) must be larger than the previous one. Otherwise, attackers can simply use the same authentication information to replay old requests. The server ensures that the counter is increasing when each random number of passwords is nonce, and rejects any wrong requests. Obviously, changing the HTTP method and/or counter value will lead to different response values.
The server should remember the nonce value of the recently generated server password random number. You can also remember to let each password expire after the random number nonce is released. If the client uses an expired value, the server should respond to the "401" status code and add stale = TRUE to the authentication header, indicates that the client should use the new server password random number nonce to resend the request without prompting other user names and passwords.
The server does not need to save any random number of expired passwords. It can simply think that all unknown values are expired. The server can only allow the random number nonce of each server password to be used once. Of course, this will force the client to repeat the authentication process when sending each request. Note that the random number nonce of the server password will not work immediately after generation, because the client will not have any chance to use this nonce.
