REST api项目的用户身份验证方法

Question

My web server has a REST API. I need to add user authentication to my app, and my thought process behind it is this:

1. Get the user's username and password from the app form
2. Encrypt the password and Base64 encode both the username and password
3. Send the data to the REST API over HTTPS
4. Web server verifies credentials, returns errors or success

Is this secure? I see a lot of mentions of OAuth2. What is it? What does it do better than my process?

Answer 1

The fact that you used the word "encrypt" for the users password instead of "hash" demonstrates you have fairly limited knowledge about this. This will almost certainly result in you messing up your authentication procedures somewhere along the line and put your users private information at risk.

A really important point about OAuth2 is that it can be used with many existing third party providers (Google, Facebook, Twitter, etc) with minimal effort from you.

You don't need to do anything to store credentials or even authenticate users. The third party takes cares of all of this and simply provides the client with a token (long random string) which is then passed to your server. Your server then talks to the third-party server to make sure the token is valid (and gain any info you need, like the users' name, email address or other information).

You really should consider using it if you can. The big companies put a lot of effort into securing their authentication methods and you gain all of that by making use of it.

A final nice point is that users don't need to create and remember credentials for (yet) another account.

Google has some docs to get you started and includes an OAuth playground to test how it works in practise.

Answer 2

A very basic explanation of OAuth2 is that the user will log into your system, with it encrypting both username and password before sending it, then if it gets authenticated, it will send back a token to the user.

Thereafter, whenever the user tries to contact the web server, it will send this token along with each API call. This is how it makes sure that non-authenticated people can't access your web server.

So basically your current method includes parts of the OAuth2 standard, but not the most important part (The token).

In your situation, how would you stop non-authenticated people from accessing your web server? If the project is small, then the risk of this is not that large.. But for larger companies, this is a real threat that needs to be dealt with.

Answer 3

You should really try to understand the difference between encryption and hashing before providing an authentication portal for your users. There are many different hashing algorithms you can use. I've personally used BCrypt in the past and I have a related SO Question about it as well. You can find implementations of pretty much all the popular algorithms in pretty much all the major high level languages these days.

Obviously if you don't want to do all that you can use an OAuth provider, who will take care of all the hard bits like storing the passwords securely, protecting the database and all the other security aspects for you. There are many reliable OAuth providers, Google, Facebook, Yahoo, etc. etc.

One thing to bear in mind would be the environment in which your app is hosted. OAuth does depend on having a connection available to the OAuth provider's servers every time a user wants to access your app. So, if you are behind a corporate firewall or similar which may block access to websites like Facebook, this might be a big problem.

I personally prefer token based authentication for my API projects. If you're not familiar with token based authentication you can read this SO Question and this link.

The general concept behind a token-based authentication system is simple. Allow users to enter their username and password in order to obtain a token which allows them to fetch a specific resource - without using their username and password. Once their token has been obtained, the user can offer the token - which offers access to a specific resource for a time period - to the remote site.