I'd read the article about WWW-Authenticate in RFC-2616.
I need to implement digest authorization of a web server on the embedded Linux environment.
I wonder if there's any way to aquire these information without a 401 response triggered.
Can't it with a trusted client just send request contains Authorization header by default?
Senario below is how I think a communication that RFC trying to explain.
Client request some document which need authorized(lack of proper header).
Client receive status 401 and the WWW-Authenticate header about further action need to perform, in order to access such document.
Client formed an Authorization header and send request again.
Related
I'm trying to set up tests in Postman to emulate my production software client. In the logs I can see that every client request is paired - a 401 followed by a 200. Evidently, the software client attempts anonymous access, and then sends the request again with the Authorization header once challenged.
I'd like to set Postman up the same way however I am seeing that Postman sends the Authorization header even if the server is configured to allow anonymous access. Is it possible to configure Postman to only send the Authorization header if challenged with 401?
The image below depicts basic HTTP authentication. The client requests /family resource and it is asked to identify itself. It does and now it can access the /family. The client then also asks for /family/photos/kids resource which is in the family realm.
The client already identified itself for /family resource, but not also for /family/photos/kids. They are in the same realm, but the server doesn't know that the same client issued a request. Or does it? How does the server know that this particular client is also allowed to access /family/photos/kids on subsequent request? Is the password and username send on every request after the user has authenticated? Is the client asked for via pop-up for every request he/she makes? Are cookies set upon first authentication?
Basic authentication requires a header sent by client. No cookies or server session
When the client requests a resource, sends the Authorization header
GET /family
Authorization: Basic token
Where token is base64(username: password). Username followed by ':' and password encoded in base 64
If you are requesting a protected resourced from your browser for example a GET request, and you do not provide the header, the browser shows the autenticathion form and remember it for subsequent requests in the same domain
When a user is unauthorised to access a page, I send a HTTP 401. Additionally, as required by the HTTP/1.1 spec, I also send a WWW-Authenticate header.
I know of at least 1 case where omitting this header causes an issue: Firebug (the Net tab will be empty).
A user can log in with both an email address or a username, and a password. The form is submitted over AJAX, and a JSON response takes care of redirecting the user after successfully logging in, or displaying an error message on failure.
On Windows Phone 8, a custom dialogue is shown when this header is present. It has fields for User name, Password, and Domain. It also has checkboxes for Show password and Remember my password.
The thing is, this dialogue doesn't work at all with the authentication process of the application.
The value of the header doesn't seem to matter, I've tried with WWW-Authenticate: form and WWW-Authenticate: blah but I get the dialogue regardless. How can I suppress this while still adhering to the spec?
From your question and the comments it seems you are doing form-based authentication, but, in order to comply with the HTTP spec, you thought you should return a 401, and, as that requires to also send the WWW-Authenticate header, you added that as well.
The fact of the matter is: Form-based authentication is non-standard, and you should not use 401 Unauthorized, which is to be used with standard HTTP authentication. So using a dummy authentication method might help you comply with the letter of the spec in terms of WWW-Authenticate, but you shouldn't be using 401 in the first place.
The spec reads:
10.4.2 401 Unauthorized
The request requires user authentication. The response MUST include a WWW-Authenticate header field containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field.
All this talk about HTTP headers (WWW-Authenticate and Authorization) makes it clear that this is about giving the client software the information needed to do the standard HTTP authentication (via a dialog in most cases).
Btw providing a custom authentication method in the WWW-Authenticate header makes sense when you want to to HTTP authentication, i.e. via the Authorization header, but use your own authentication scheme, rather than basic or digest. This of course requires a client that understands that custom scheme.
So what could you do instead? As form-authentication is non-standard, this is not defined in the specs, but how about redirecting the user to a/the page with the login form using a 307 Temporary Redirect, perhaps adding information so you can automatically redirect the user back to the page he wanted to access after verifying the credentials.
I am trying to know when is the Authorization header sent automatically by the browser and when not.
By reading several posts and experimenting, I found out that the browser only sends the credentials:
When using Basic authentication, and only if the user input the username and password directly in the browser window (not, for example, if they were supplied in an XMLHttpRequest).
When using NTLM authentication
I would like to find a document which states when the browser should and should not send the header automatically (something like a specs document). I am especially interested in OAuth and Bearer Authorization header types.
Usually web browsers send Authorization header when it received 401 response. RFC 7235 "Hypertext Transfer Protocol (HTTP/1.1): Authentication
" says:
The "Authorization" header field allows a user agent to authenticate
itself with an origin server -- usually, but not necessarily, after
receiving a 401 (Unauthorized) response.
If you are finding specifications for HTTP authentication, see "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" which provides the list of authentication schemes and the references.
I'm just reading Paypal's API documentation, e.g. Adaptive Accounts API
My question: What's the reason/advantage of using (custom?) HTTP Request Headers for authentication instead of "normal" POST/GET (or even COOKIE) variables?
In the mentioned example PayPal uses the following HTTP Request Headers:
X-PAYPAL-SECURITY-USERID
X-PAYPAL-SECURITY-PASSWORD
X-PAYPAL-SECURITY-SIGNATURE
X-PAYPAL-APPLICATION-ID
X-PAYPAL-DEVICE-IPADDRESS
X-PAYPAL-REQUEST-DATA-FORMAT
Why use HTTP headers rather than something in the body of the request?
By keeping your authentication info separate from the payload (the data you are transmitting) you make it easier to handle authentication at an earlier stage in the request pipeline. For example, a gatekeeper server can receive requests and authenticate them by looking only at the headers, and then pass them along to the module/server/class that does parses the request body and does the real work.
If the request fails authentication, it can be rejected before it even gets near the code that deals with the money.
Of course, you can architect your system this way no matter what, but keeping it in the headers means you don't need to parse the request body or even look at it. You also don't need to worry about adjusting Content-Length: if you wanted to modify the headers before passing it along to another server.
Why use custom HTTP headers rather than WWW-Authenticate or Cookie?
I think this is simply because PayPal wants a more robust scheme than either of these can accommodate. WWW-Authenticate only allows for basic (cleartext) and digest (MD5) authentication, and many better schemes have been developed since the spec for these was written. They also don't allow for more than a username and password.
Cookies are technically opaque bits of data that you receive from a server and pass back to it unchanged. Again, they could tell you how to generate the info that you pass along in a Cookie header, but that wouldn't really be following the spec, so at that point, why not just use some custom headers?
The HTTP access authentication process is described in "HTTP Authentication: Basic and Digest Access Authentication", look here.
User agents are advised to take special care in parsing the WWW-Authenticate field value as it might contain more than one challenge, or if more than one WWW-Authenticate header field is provided, the contents of a challenge itself can contain a comma-separated list of authentication parameters.
If the connection is trusted between two parties and SSL is implemented, HTTP Authentication is a simple to implement way to authenticate between two fixed parties. The connection is simply rejected at the traffic level if the authentication fails.
I don't think Paypal uses HTTP Authentication for payments? It's just for you to access API features to build your own admin interface for Paypal accounts?