search

miguelgrinberg / REST-auth

Example application for my RESTful Authentication with Flask article.
http://blog.miguelgrinberg.com/post/restful-authentication-with-flask
MIT License
922 stars 337 forks source link

fix #3: Separate token authentication mechanism #6

Closed micjabbour closed 5 years ago

micjabbour commented 7 years ago

The blog post was excellent, it made many things clear to me. Thanks for sharing it :)

I just feel uncomfortable with generating a new token using a token. One of the main advantages of using tokens (instead of just authenticating using username/password) is security. A quote from the blog post:

Tokens are usually given out with an expiration time, after which they become invalid and a new token needs to be obtained. The potential damage that can be caused if a token is leaked is much smaller due to their short life span.

In the current implementation, if a token is leaked, the attacker can use it to generate a new token before the leaked token expires, then he/she can repeat the same procedure with the newly generated tokens. This renders a token as powerful as its corresponding username/password pair (except that it needs to be renewed before its expiration period, and I don't think that this would really stop a malicious attacker).

In this pull request, I have used two HTTPBasicAuth() objects, one that authenticates using a username/password pair, and one that authenticates using a token. This way, a view function can expect authentication using either one of the two mechanisms (but not both). So, get_token() only works with credentials, and get_resource() only works with tokens.

P.S. : This also makes the verify_password functions cleaner and more understandable.

Thanks for your time, if I am wrong with anything, feel free to correct me :)

miguelgrinberg commented 5 years ago

This issue will be automatically closed due to being inactive for more than six months. Please reopen if you need more assistance.