and thank all of you for viewing this question.
I am not sure to on how do this so i am asking for the community help on this matter.
I read int his post Can you help me understand this? "Common REST Mistakes: Sessions are irrelevant" that sessions are not "completely" advised on the REST convention, and that all authentication should be made using HTTP Basic authentication or Digest.
Ok, so far i get it.
But has far has i know, basic authentication is made on the actual server against a regular non-encrypted text file.
Would it be going against the convention, putting the username/password in the http request parameters, instead of passing them down trough the headers and letting the web server do the authentication?
This way, for every request made, the user/pass parameters would be checked and managed using my own logic. I mean using a database table, that has all the info necessary for the application.
The method I currently use is the first request is for a auth token via a POST method, which contains Headers of Username and Password, these are then verified against my authentication methods. If the credentials are valid, I return a time limited token. All subsequent requests must have the auth token as a header, which is checked and if valid access is allowed. I maintain the list of valid token in code and expire them as required. This is faster than having to validate the username & password on each call and is slightly safer than the username & password being passed in with each call as a token could be stolen, but it is only valid for a small period of time.
All of this this must be run under SSL otherwise the data is not secure and users credentials can be read.
Basic auth is handled by the server however the server chooses to handle it. There certainly doesn't have to be a plaintext file containing usernames and passwords! My current client stores passwords in a 1-way salted hash in their database. On an incoming request, the plaintext password is pulled from the header, salted, hashed, and them compared to the database value.
Putting a password in a request parameter is a really bad idea. What happens when a user copies and pastes a URL to email to their coworker?
Related
First of all, I am sorry for my bad English.
I am writing an app with a backend, which I want to make safe. I am using HTTPS for the connection, but a lot of people say that this is not enough protection.
At the moment, my user credentials are sent to the server via JSON format as plain text, which isn't a good way, I guess. At the server, my password is hashed with a random salt and stored in the database.
If the login is successful, an authentication token is generated and sent to the client. The client is using it as a header.
Do I need to do more? I read something about digest access authentication. Should I implement this authentication method, or is there a better way to make my login safe? Or is this the right place to use this authentication method?
I would like to know if the following design for token-based authentication is sound.
Client posts login credential
After validating, server generates (session_key, expires_at) <- (a 256-bit pseudo-random string, some date in the future) and save it in the storage system of choice.
Server sets the session_key in the HTTP-Only cookie in the response.
Server sets the response payload {session_key: ..., expires_at: ...}. The reason is that non-browser clients do not have cookie and they will read this payload, locally store it for the future use.
Concretely, I think the system needs to send the token in the payload as well as a cookie for non-browser clients. Is this a common practice? Or am I missing something important, and there are better alternatives?
As I pointed out in another question, this is fine. It doesn't expose the session key any more than if it is only in a cookie. This could only happen if the attacker can call your authentication endpoint with a valid user/password combo.
Make sure your authentication endpoint does not accept valid sessions and echo back their key as that could expose you to CSRF and session stealing!
For alternative authentication methods, check out the Web Authentication Guide, I put together.
I want to create a authorization mechanism for an application based on WebAPI and AngularJs.
I've seen some articles, which use BasicHttpAuthentication, but i really don't like the whole idea of sending username, and password on every request. The more it doesn't fit for me is because i want to use OpenId authentication, where you don't have username/password pair.
I'm thinking about a solution, but I don't really know how to implement it. The concept is that user is authenticated as in an usual Web application - posts a form with user / password or selects an OpenId provider. If the user is authenticated succesfully, it is placed in a static object, which stores the User object for a certain ammount of time. Next a usertoken is generated and passed to the Client Application. The client passes the token on each request to the server, if the user exists in the above mentioned static object with the appropriate authentication token it is authorized to get the data.
Firstly - Do you think this is a good approach to the problem?
Secondly - How should I pass the authentication token, WITHOUT using cookies? I guess it should sit in the request headers, like in BasicHttpAuthentication but, I really dont' know how to handle it.
BasicHttpAuthentication
I'm with you on feeling dirty about caching the username and password on the client and forever transferring it with every request. Another aspect of Basic authentication that might work against you is the lack of sign-off. Other than changing the password, you can't "invalidate" a basic authentication session. Tokens on the other hand, will typically offer an expiration date, and if you want server-side invalidation you can check the issue date and say "any tokens older than issue date xyz are invalid".
Server State
You mention "If the user is authenticated successfully, it is placed in a static object". But this is independent of the token? This sounds like you're wanting to implement server state management of authentication sessions, but this isn't strictly necessary. The token itself should be sufficient for user authentication, managing server state is another potential obstacle. Server state can become difficult to manage when you factor app-pool recycles or web-farm environments (what if you want two services to share the same authentication token, but not require communication with a central "authentication server" for storing the state / session?)
Passing Authentication Token
Headers is definitely a good place for it. Really, where else is there? Cookies, Headers, Message. Other than a browser client, cookies don't make a lot of sense, and including it in the message can muddy your message formatting a bit, so headers is the only remaining option that makes much sense in my view.
Client Implementation
You've not specified, but I suspect you're interested in calling the service from .NET? In which case System.Net.Http.HttpClient could be your friend. In particular, the DefaultRequestHeaders collection. You can use this to add a custom header to store your authentication token.
Server Implementation
When researching ASP.NET authentication recently, I learned a lot about customisation by examining the Mixed Authentication Disposition ASP.NET Module (MADAM). I wasn't interested in using MADAM as-is, but learning about it from that article and examining the source code gave me a lot of ideas of how I could insert my own authentication module into the web stack.
I'm implementing a rest api to using the new web api framework. This api will be consumed by other companies so we'll be adding an authentication method.
In relation to authentication, I'm thinking to implement something based on tokens. Something like this
client provide credentials to login method
system authenticate client and send a token
client uses this token on following api calls
I wonder if this schema is useful for my scenario. Operations will be mainly atomic, basically clients will periodically ping this api to get some specific data, so not sure if make sense having a session token (at some point the token should expire and not sure how to manage this).
How would you recommend to implement authentication schema for this scenario?
When you generate a token I would store it in a database with a foreign key back to the authenticated login's primary key. I would also (with the token) store the date and time it was established, and a timeout period (you could set this per token, or store it in a config). Check the token/time everytime the service is pinged by that user, then force them to reauthenticate after that time expires (by checking it against the created date stored with the token).
This would make sure that the login information is only getting transmitted after the token expires, when a new token is generated it would delete the old token record.
Am I understanding your requirements right?
Making a token based authentication scheme like this is not easy.
I don't really have an answer for how you could implement it in a good and secure way. But will offer some thoughts off the top of my head about issues you will have to deal with:
The token generation need to be well randomized and the tokens need to be "sufficiently" (for some definition of sufficient) long in order to prevent someone from simply sending a bunch of different tokens to see if he "gets a hit"
The above issues should not be too difficult to implement. But the more tricky thing to figure out is:
How you can you reliably verify that the token has not been "kidnapped".
If the token is simply some random string, then anyone who happens to "see" it in tranfer (use SSL) will be able to assume the identity of the use for which the token was generated.
The token, when received by your service will let you know that:
Your application issued the token to user/application/entity X
The token is intact (has not been changed)
Any other thing you store with the token (is it expired etc)
But it will not without further effort let you know for sure that it was sent by user/application/entity X. It could be Y who has managed to get hold of the token.
That is the case for many authentication schemes of course, so depending on just how sensitive your data is, and also on what kind of operations can be done via you service, it may not be a huge issue for you.
I have an API endpoint https://www.example.com/api/authentication which takes username and password as input and returns an authentication token.
In terms of passing username and password, I have two options (at least), namely:
HTTP Basic Authentication (which passes credentials as part of HTTP headers)
HTTP POST parameters
I understand that neither method provides encryption (hence the use of HTTPS/SSL). I also understand why using HTTP GET is is a Bad Idea.
Is there any real difference (aside from the fact that basic authentication feels more idiomatic) between the two methods?
The difference is that basic authentication is a well specified challenge/response scheme that all browsers understand and it is the server that starts it by telling a client that it requires (basic) authentication for a realm. This triggers the browser to show a popup to the user to enter a name/password which it then passes in the headers as you described.
In your second example you have to do all that in your own customized way and create your own login form for the user (etc).
If you deduct this process to the single step of passing the username/password from the client to the server I have to agree that there isn't that much difference but basic authentication implies a bit more than just that.
HTTP Basic authentication implementation is the simplest technique for enforcing access controls to web resources because it doesn't require cookies, session identifiers, or login pages; rather, HTTP Basic authentication uses standard fields in the HTTP header, obviating the need for handshakes.