There seems to be 2 HTTP Authentication: Basic access authentication and Digest access authentication
So I think in general, a user tries to access a URL, and the web server returns 401 Unauthorized, and then the browser
pops up an app window, asking for username and password, and then set the credentials in the HTTP headers then sends the HTTP request again.
What about http://peter:mypassword#www.somesite.com ? Is that supposed to not wait for the 401 to come back but provide the username and password in advance?
Some how, I tried http://peter:mypassword#www.google.com or yahoo but inside of Fiddler (to monitor net traffic), I don't see any credential info in the HTTP request?
You still need to send the 401 on the server side. The user:pass#host is just a convenience to avoid displaying the login dialog.
If you think about it, this makes sense, because if you don't send the 401 with the header explaining which method to use, the client doesn't know how to format the credentials.
(There are actually any number of schemes, not just Basic and Digest.)
For some understanding of it, there is a Railscast that talks about HTTP Basic Authentication and adding it to a Rails project and how it looks like on a browser: http://railscasts.com/episodes/82-http-basic-authentication
Related
I am building an oauth login flow and I am not sure if I have done it wrong because I will need to send the bearer token back via redirect URL, like /oauth2/redirect?token=[TOKEN]. But isn't it not recommended to have token passed along through URL? As it is pointed out in this thread:
Don't pass bearer tokens in page URLs: Bearer tokens SHOULD NOT be passed in page URLs (for example, as query string parameters).Instead, bearer tokens SHOULD be passed in HTTP message headers or message bodies for which confidentiality measures are taken. Browsers, web servers, and other software may not adequately secure URLs in the browser history, web server logs, and other data structures. If bearer tokens are passed in page URLs, attackers might be able to steal them from the history data, logs, or other unsecured locations.
I must have missed something in the whole flow and would like to understand more about this matter. Any input is appreciated!
UPDATE
Might not be correct but this is my understanding after some digging. The three means to pass token:
URL (not preferable)
Auth header
Request body
But under the oauth redirect use case, option 2 and 3 not feasible. So option 1 is the only option available. If really needed, token can be encrypted to ensure security.
I think this only means, that you should not use a GET request when the server requires the token, instead you should use POST or whatever is appropriate. In a GET request the parameters are included in the URL and those can end up in logs or other histories, other request types will send the paramters separat from the request URL.
P.S. BTW if you are not implementing the OAuth server yourself, you won't have to send a redirect url containing the token.
The basic auth header which provides a little extra security as it's required to be through TLS:
In the case of a "Basic" authentication like shown in the figure, the exchange must happen over an HTTPS (TLS) connection to be secure.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication
Also, the headers aren't logged in easy places like browser history.
From the spec,
it SHOULD NOT be used
unless it is impossible to transport the access token in the
"Authorization" request header field or the HTTP request entity-body.
https://www.rfc-editor.org/rfc/rfc6750#section-2.3
I built a simple authentication system for my backend API with Express using Cookie-Parser and/or sending the Token to the front end.
It works like this: the user makes a post request to the login route with the username and password, and if it matches, he gets back both a .json response with the token and a cookie set with the token.
I thought it would be nice for the frontend development and authorization purposes to have the current user available in every successive request after the login. So, I set a middleware that searches if there is a token, tries to find a user in database with the corresponding ID, and set the user info (without the password) as a parameter in the request object (req.user).
What I wanted to know is:
Is it a bad practice to put the user info in the request? Does it lead to security problems? Or maybe the database query in every request could overload the server if the app scales to much?
This is my first backend API, I'm trying out different ways of doing things, but I'm not aware of the best practices in the field. Any help is very much appreciated!
That is why there is encryption and in this context it is an ssl ticket. If you add login details to the request you NEED to make sure that the http response is encrypted. Once it is encrypted it is ok to do what you are doing. If it is not, an eaves dropper can snatch up that data from sniffing on your network.
I understand that OAuth2 is a good way to secure access to a REST API. I also understand that unlike in a simple website or in a SOAP API, in a REST API you want to use the right HTTP method for the right task. That is GET to read data, POST to write, etc.
My question is, when doing a GET call to a REST API secured via OAuth2, how do you protect your access token ? I don't see any other way to pass it to the server than in clear view in the URL, so isn't it that anybody that can see my call on the network could hijack my authorization ?
A HTTP request has a couple of major components:
The method
The url
Headers
Body
The OAuth2 Bearer token is usually sent in the headers, as such:
GET /thingy HTTP/1.1
Host: api.example.org
Authorization: Bearer [secret]
As an aside, this assumption is not really correct either:
so isn't it that anybody that can see my call on the network could hijack my authorization ?
If you don't use HTTPS, anyone can still see this token even if it's in a header. If you do use HTTPS, putting a token in the url shouldn't allow anyone else to snoop. However, putting secrets in urls is considered a bad practice for different reasons. Specifically, people don't like it because the tokens can end up in a browsers history and in logs. This increases the chances of it accidentally falling in the wrong hands.
Typically, it seems that most web applications will respond with a 302 if a new user signs up or an old user signs in.
i.e.
client ---signup req-----------------------> server
server ---302 Temporarily Moved or Found---> client
Doesn't it make more sense to redirect with 200 or just say Found and separately redirect the client? There is no resource that has temporarily moved in this case, rather they've been successfully authenticated. I'm confused since 302 Temporarily Moved and Found seem to contradict each other based on what their names indicate indicate.
RFC 1945 doesn't indicate anything about the Found status code but only the Temporarily Moved.
I figured out the answer. Perhaps this will help someone else.
There are different ways of doing authorization. Some are standardized, others are not. Examples are Digest Auth (in HTTP Spec), Basic Auth (HTTP Spec) and Forms Based Auth.
There are pros and cons to each method. But, Basic and Digest Auth both give 401 Unauthorized Codes. Forms-Based Authorization however prefers using the 302 Temporary Redirect to a login page. This is so that it gives the control of application login experience to the developers themselves.
Forms-based auth is the most popular even though it is not standardized. Typically the client sends a request, server returns 302, client sends another request at new login page, server sends back with set-cookie headers.
I'm currently building a web application (utilizing Zend Framework) and have gotten some of the basic HTTP status codes down, such as:
404 on missing controller/action
500 on server exception
3xx returned by Apache
At the moment I have just implemented some basic ACL checking that the user is authorized to access a certain resource. It's implemented as a controller plugin, doing its thing on the routeShutdown event. It works like follows:
Get the role of the user. If the user is not logged in, assign the role of 'guest'
Check that the user's rule has access to the resource
2.1. If the does not have access to the resource and is a guest, save the resource he was trying to access, and forward him to a login prompt. Once he has supplied his credentials, he is redirected back to the original resource (via a HTTP redirect status code)
2.2. If the user is authenticated and the ACL denies him access to the resource, he is forwarded to the error controller, to an action I've called noPrivilegies.
If the user does have access, let the request continue as usual.
Now, my questions:
Can/should I use HTTP 401 for the 2.1 scenario? It's not like I want a WWW-Authenticate header field sent by the client. I just need him to login through my login-form. But I still think that the request wasn't a 200 OK, since he didn't get access to the requested resource.
Can/should I use HTTP 401 for the 2.2 scenario? Same reason here, WWW-Authenticate won't help. Perhaps it's better to use HTTP 403 Forbidden?
Do you recommend any other status codes for these two scenarios?
What other status codes do you usually return from your application, and when are they applicable?
Provided that the guest role may be allowed to perform some actions, then no 4xx response or other form of error is warranted at stage 2.1 of your process because not being logged in is not an error.
Neither 401 nor 403 is really ideal for an application-level "permission denied", but weighing 401's "The response MUST include a WWW-Authenticate header field" against 403's "Authorization will not help", I would say (and most cases I've encountered to date seem to agree) that 401 is the appropriate response if you are requesting HTTP level authentication before proceeding and 403 is appropriate in all other cases. So probably 403 in your case.
I think that 403 is the correct response. Per the HTTP spec, 401 is for cases where HTTP-level authentication is possible and required, 403 is for cases where the user does not have permission to access the resource. In the case of your app, the user has logged in, and it's unreasonable to expect that s/he will be able to use a different account.
Normally I don't ever use the status codes to report 'application' level authentication failures. That's generally reported via the app.
And it makes sense to do that; because they can access the 'page' from a 'http' sense; they just can't access your applications processing of that page, if that makes sense.
What I'm saying is generally you don't worry about the codes, or set them yourself at all, when returning data to the client. Leave it to the webserver and provide an 'abstracted' method of responding; i.e. the typical 'invalid username or password' page, etc.
Just my view, though.
i've recently implemented something that works in a similar way, we return a 401 response when a user has to login and a 403 if after login they've tried accessing something that they don't have permission to access.
you can also set the reason phrase in the http response to something to denote the reason for the failure.
Even not specifically stated in HTTP spec, the common practice is
401 - For authentication error
403 - For authorization error
Try not to use 401 if you don't want authenticate user. I recently encountered a problem with a HTTP client (not one of the popular browsers) that it logs an error when it sees 401 but not WWW-Authenticate header. Granted this is a bug on the client side but it shows how people perceives 401.