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.
Related
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
I have created JWT based Authentication in my Web API application.
I am not able to figure out the difference between
Basic Token
Bearer Token
Can someone please help me?
The Basic and Digest authentication schemes are dedicated to the authentication using a username and a secret (see RFC7616 and RFC7617).
The Bearer authentication scheme is dedicated to the authentication using a token and is described by the RFC6750. Even if this scheme comes from an OAuth2 specification, you can still use it in any other context where tokens are exchange between a client and a server.
Concerning the JWT authentication and as it is a token, the best choice is the Bearer authentication scheme.
Nevertheless, nothing prevent you from using a custom scheme that could fit on your requirements.
Basic authentication transmits credentials as user ID/password pairs, encoded using base64. The client sends HTTP requests with the Authorization header that contains the word Basic word followed by a space and a base64-encoded string username:password.
Authorization: Basic ZGVtbzpwQDU1dzByZA==
Note: For basic authentication, as the user ID and password are passed over the network as clear text (it is base64 encoded, but base64 is a reversible encoding), the basic authentication scheme is not secure. HTTPS / TLS should be used in conjunction with basic authentication.
Bearer authentication (also called token authentication) has security tokens called bearer tokens. The name “Bearer authentication” can be understood as “give access to the bearer of this token.” The bearer token is a cryptic string, usually generated by the server in response to a login request. The client must send this token in the Authorization header when making requests to protected resources:
Authorization: Bearer < token >
Note: Similarly to Basic authentication, Bearer authentication should only be used over HTTPS (SSL).
For more information link1, link2
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.
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.
The HttpUnit API for webclient says that "Will only send the authorization header when challenged for the specified realm." What does challenged mean in this case? How does HttpUnit recognize a challenge?
This refers to the way HTTP Authentication works:
When accessing a protected URL (for the first time, with no credentials included in the request), the server will send back a response that has a status code of 401 Unauthorized and a WWW-Authenticate header set to something like Basic realm="My Realm". This indicates that Basic authentication is needed for the given URL and the realm is named 'My Realm'. This is the challenge - the user agent is being informed by the server that the URL it tried to access requires authentication and it should send back the user credentials. The user agent will typically prompt the user for credentials and then retry the request, this time with a Authorization header set to something like Basic rXflcjMwYXxz where the second part is the Base64 encoded username and password pair.
In case of the HttpUnit method you've linked to, you'll see that it requires a realm, username and password. I imagine that when the a URL is accessed, if it gets back a 401 (the challenge) from the server, it'll compare the realm you passed it with the realm in the response; if it matches, it'll attempt to authenticate with the username and password supplied.
References:
RFC entry for 401
Headers for authentication
Basic access authentication
When the server responds with a 401 error, the HttpUnit throws an AuthorizationRequiredException. We can use getParameter("realm") of the exception to get the realm and send a request again with this realm name.