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.
Related
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.
I have a service that I would like to access from cURL and browser on which is enabled LDAP Basic Auth. But this service is a backend of a proxy on which is enable another Basic Auth.
So to reach my service my request has to send two different Basic Auth headers. Is that possible ?
It's possible to authenticate against your application and against a proxy in the same request.
Authorization header
To authenticate against your application, use the Authorization HTTP header:
4.2. Authorization
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. Its value consists of
credentials containing the authentication information of the user
agent for the realm of the resource being requested.
Authorization = credentials
If a request is authenticated and a realm specified, the same
credentials are presumed to be valid for all other requests within
this realm (assuming that the authentication scheme itself does not
require otherwise, such as credentials that vary according to a
challenge value or using synchronized clocks). [...]
Proxy-Authorization header
To authenticate against the proxy, use the Proxy-Authorization HTTP header:
4.4. Proxy-Authorization
The Proxy-Authorization header field allows the client to identify
itself (or its user) to a proxy that requires authentication. Its
value consists of credentials containing the authentication
information of the client for the proxy and/or realm of the resource
being requested.
Proxy-Authorization = credentials
Unlike Authorization, the Proxy-Authorization header field applies
only to the next inbound proxy that demanded authentication using the
Proxy-Authenticate field. When multiple proxies are used in a chain,
the Proxy-Authorization header field is consumed by the first inbound
proxy that was expecting to receive credentials. A proxy MAY relay
the credentials from the client request to the next proxy if that is
the mechanism by which the proxies cooperatively authenticate a given
request.
Basic Authentication
For more details on the HTTP Basic Authentication scheme, check the RFC 7617:
2. The 'Basic' Authentication Scheme
The Basic authentication scheme is based on the model that the client
needs to authenticate itself with a user-id and a password for each
protection space ("realm"). [...] The server will service the request only if it can validate
the user-id and password for the protection space applying to the
requested resource.
[...]
To receive authorization, the client
obtains the user-id and password from the user,
constructs the user-pass by concatenating the user-id, a single
colon (":") character, and the password,
encodes the user-pass into an octet sequence,
and obtains the basic-credentials by encoding this octet sequence
using Base64 into a sequence of US-ASCII
characters.
[...]
If the user agent wishes to send the user-id "Aladdin" and password
"open sesame", it would use the following header field:
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
[...]
Your cURL command line would be like:
curl -X GET \
-H "Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==" \
-H "Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==" \
"http://example.com/api"
Important! Please note that the name of these HTTP headers are unfortunate because they carry authentication data instead of authorization data. Anyways, these are the standard headers for sending credentials in HTTP.
I'm sending username and password in the HTTP Body for authentication to each controller action in a Web API. I do the authentication in each controller using the username/password. It's using SSL.
Are there any security reasons why it's better to send the authentication credentials in the HTTP Header than in the HTTP body?
If I was using Basic Authentication I can see how having the credentials in the header are necessary as in this question but I'm not so I don't see the purpose. It seems just as secure in either as long as it's using SSL.
From an SSL perspective the security of the credentials in header (HTTP Basic auth) or body (e.g. form based logon) of an HTTP request is equal.
However if the client is a regular web browser you should consider the following:
Browsers cache the credentials used with HTTP basic authentication the users usually face the problem that for performing a log-out they would have to close their browser.
On the other side a form-based logon usually created a session cookie that is time restricted and can be deleted any time.
Let me quote HTTP 1.1 RFC specification from www.w3.org.
10.4.2 401 Unauthorized
The request requires user authentication. The response MUST include a
WWW-Authenticate header field (section 14.47) containing a challenge
applicable to the requested resource. The client MAY repeat the
request with a suitable Authorization header field (section 14.8).
14.8 Authorization
A user agent that wishes to authenticate itself with a server usually, but not necessarily, after receiving a 401
response does so by including an Authorization request-header field
with the request. The Authorization field value consists of
credentials containing the authentication information of the user
agent for the realm of the resource being requested.
Why the credentials intended to prove user identity (Authentication) passed in Authorization header?
You can see it like this. The server says to the client "Please authenticate before accessing this resource" and sends information on how the client should do the authentication (WWW-Authenticate). The client is responsible for authenticating and then sends proof of that authentication to the server (Authorization).
The Basic authentication scheme messes things up because the authorization is a username and password, that is, you authorize by authenticating against the server itself (showing you know a user and password).
Nevertheless other schemes allow the client to authenticate with a third-party and only send a proof of the authentication to the server. The server can verify the authorization and may not know who the client is (although it typically does).
Note This is only a rationalization. I don't mean to say this was the motive behind the chosen names.
One possibility is that it is talking about the authorization from the user's perspective, not the server's.
There are actually two authorizations going on:
The user authorizing the client to act on their behalf.
The server authorizing the user to access its resources.
If we assume the header is named after 1) then we have:
The user authorized the client to act on their behalf. That authorization goes in the Authorization header. The server then used the user's authorization of the client to authenticate the user (confirm the client is acting on behalf of the user). Now it knows who the user is, it will then do its own separate checks for 2), to see if the user is authorized to perform the request.
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.