Oauth2's token question?
1. Recently, when I looked at the oauth2 protocol, I found that it was mentioned that after changing an token, with an account password to the server, the request would use token;
.
I always feel that this token is equivalent to a password at this time. After someone gets it, it can still be used directly. Although there is an expiration time, such as introduced by Wechat official account , its access_token expires in two hours, but within two hours. Isn"t it equivalent to getting the account number and password? It doesn"t make sense to get your account number and password for one minute, let alone two hours.
2. In addition, don"t you have to send appid and appends when you get access_token for the first time, isn"t that also not safe? One send and each send only reduces the possibility of exposing AppSecret a little bit, and it doesn"t feel good in terms of security.
first of all, there is no absolutely secure system, and all security mechanisms just increase cracking and reduce risk as much as possible.
oauth mainly solves the problem of cross-domain authorization. For example, if you want to use your Wechat account to log in to a third-party application, it is impossible to log in directly using the Wechat account password, which increases the possibility of your account password disclosure. Oauth uses the following strategies to improve security.
- 1. Third parties need verification.
if you want to use Wechat oauth, then you need to go to Wechat to apply for appid and appSecret, and then the oauth provider will review it, reducing the possibility of malicious third parties stealing your information through oauth.
- 2. Limited permission control.
when using oauth, ask you to display the authorization specific operation (scope), for example, you can only authorize access to account information (profile picture, user name, etc.), so for the oauth provider, the mechanism token is leaked, and you can only obtain account information and do no other operations, so the risk is controlled.
the entire oauth process uses tls encryption and certificate verification, which reduces the possibility of tampering or exposure during data transmission.
token can be invalidated actively or passively. When a token leak is found, it can be easily revoked, so that token cannot be used.
so on the whole, oauth is not a perfect essential oil, but it is indeed the best solution for these scenarios under the current technology system. How else can it become the standard.
suppose you have made an application that requires access to the user's Wechat information, and the end user needs to log in to Wechat for authorization before Wechat provides token to your program. You can get the information of user Wechat directly by using token. If you don't use oauth, the end user doesn't want to provide Wechat's username and password to your program? Appid and appSecret can only guarantee that your program sends the token to Wechat, that is, the token sent to you can only be used by you, otherwise other applications will not be able to get the user Wechat information with this token?
