Q:

Analyze my custom web authentication scheme, based on a token derived from username and password

To avoid having the user to login every time his session expires, I want to implement a token based authentication system.  
My scheme works like this:

Send the user login (send name + password) via $.ajax() to a https URI
Create a token via $token = bin2hex(openssl_random_pseudo_bytes(16));
Save $token, userid and date in a database (only accessible by SSL)
Echo the $token and userid to the client
Save the $token and userid in html localStorage on the client
When doing an $.ajax() from client always send userid and $token as POST
Serverside, match the provided $token and see if it is still valid (date not expired).
If it's alright, continue to deliver the requested material

Can you analyze my scheme?
Many people advise against implementing custom authentication processes, as they are often vulnerable to attacks.  This makes me suspect that my approach may also have flaws.  Can you reveal these flaws to me?

A:

So there are a few reasons why you don't want to do this, although I do not understand the code you presented as I do not deal with that. You should use a third party library to manage your sessions. There are several reasons...

Code is vetted, tested and improved across a much wider audience when you use a built in or well know authentication scheme.
When and if you leave, someone is not stuck dealing with a custom created authentication mechanism
There are probably vulnerabilities in the code, it may or may not be directly in your code but in a service you call, updating that single service may cause issues through the rest of the code, such as deprecated arguments and variables.  This may not make your program less secure but it may break it.
Self support is tough, especially when you do a good job and it is running without issue for a year or two, then bam!! in the middle of another project something breaks and you have to take the time to troubleshoot it from the bottom up.
CYA, if you make a mistake and something bad happens, you are the one people will come back to and ask, why didn't you use this or that scheme that is not vulnerable to some attack and you will have to explain that.

Anyway, I hope that helps

A:

On the face of it, with a MITM I can just get access to your webapp as long as one your users is using my "wifi"
Also, why use something unproven when you can use proven technology (OAuth2 would suffice for your purposes and that has been security-tested) 
And you have no checking built for brute-forcing your "token" meaning I can just brute-force as soon as I get a "userid" (probably a number so easily guessable).
Also, this example lacks protection against SQL-injections, meaning I could just give mysql a valid token and login to anyone's account.
Solving all of them (without creating hidden backdoors / etc) is nigh impossible for one man. Just use one of the libraries available from the open source community, one that is tested and verified!

A:

Not a bad start. Some things to watch for:

If login fails, don't reveal whether the user exists
Implement some form of brute force protection
Provide a change password function; require the previous password
Perform password strength checking
Sessions usually have both inactivity and absolute timeouts
Store passwords securely, e.g. bcrypt
Use an anti-CSRF token
Let users self-manage sessions

And that's just authentication and session management. There's a whole load of other security considerations: SQL injection, cross-site scripting, use of SSL/TLS, etc.
Most authentication libraries do NOT solve all these problems in the default configuration.

