I understand that the OP is working on their own solution called "Flask-Stormpath" but some of the arguments against Flask Authentication does not make sense to

I understand that the OP is working on their own solution called "Flask-Stormpath" but some of the arguments against Flask Authentication does not make sense to me at least and I have been dabbling in Flask for a while. First, flask was designed with a purpose. The creator makes it very clear "The “micro” in microframework means Flask aims to keep the core simple but extensible. Flask won’t make many decisions for you". So now that we have that out of the way, I will point some specific things from this post that do not make sense to me. May be I didn't get the point. "Set up a SQLite3 / MySQL / PostgreSQL database server." What do you mean here ? Should we not setup a database server ? Flask does not force you to use any specific database. In fact, personally I prefer that I can use sqlalchemy etc. without worrying about being tied to a specific ORM. That's the point of flask for me. "Write a User model (and define a users table)." Sure. Flask wants you create your own user table. But why is that a big deal ? I mean yes most user models have username/email,pwd_hash etc. I would rather create my own model depending on my application need vs taking a pre-defined model. This is not at all difficult and again, the whole idea is that you want that flexibility and hence using flask. "Build your own login view code to create new user accounts, and store them in the database." Again, I can create custom apps based on the specific requirements if I have this flexibility. But ok, I see your point. Stuff like this can get overwhelming. But then again, flask gives me so many tools that I am not worried. Want to do notifications/subscriptions ? boom, plug in Signals. stuff like that. "Implement your own crypto, usually by importing from the werkzeug library and hashing user passwords yourself." Wait,what ? Who says that flask wants you to implement your own crypto ? You can directly use py-bcrypt or others. It is as easy as below. There is no implementation here. bcrypt.hashpw(password,bcrypt.gensalt()) "Hashing user passwords when they attempt to login, then comparing these hashes to the database." What's wrong with this again ? "Storing custom user data either in the same database table as your accounts, or relating it via a foreign key." Now it seems like you are justifying Flask-Stormpath more than the fact that we should not be doing these ? "Storing user data in cookies and sessions directly to handle logged-in state." Ok, I agree here. Flask does make it a little harder dealing with sessions since the default is cookies for everything. But again, because flask does not want to enforce any particular datastore, it gets tricky. Then, you came up with these conclusions: "Almost nobody hashes passwords correctly." Is this a little far fetched conclusion ? I would think so. And even if people don't hash password correctly, it is not flask authentication's fault. It is the developer's fault. "Almost nobody structures their user database to allow for scaling." What do you mean by "scaling" ? Do you mean updating user models, adding millions of users ? What does scaling have to do with authentication ? Overall, I realize that you are presenting arguments for Flask-Stormpath and as a flask dev, I will definitely take a look at it. But most of your arguments for Stormpath are not the reasons why flask has a bad authentication if there is such thing.