Demos don't follow best practices

[Dreamsorcerer]

The documentation is a little confusing, as it mentions that identity should not be something like a user ID or login. However, both demos appear to ignore this advice and it seems that userid == login == identity.

If trying to get started quickly by going through the demos, then it appears you would end up following bad practices.

[Dreamsorcerer]

This appears to extend to the more complete aiohttp demos as well:
https://github.com/aio-libs/aiohttp-demos/blob/master/demos/blog/aiohttpdemo_blog/db_auth.py

[Dreamsorcerer]

@asvetlov More generally, what is the rationale for this advice? What issues might we face by revealing the user ID or login?

Worth noting that this isn't even revealed when using the session backend with EncryptedCookieStorage, as the session is encrypted.

[yanxurui]

My 2 cents:
If the identity is user login and it is stolen, attackers can login with your login. Since your login usually doesn't change, you don't have a way stop the bad actor.
Using an EncryptedCookieStorage still has the same risk above. That is, as long as I have your encrypted session, I have your account.

[Dreamsorcerer]

I feel like if you can access a cookie, you can probably also access the user's login details anyway. Expiry times can also reduce this risk.

If developers want to ensure that a session can be revoked, then it would be a good reason to use something different for the ID. However, revoking a session needs to be an explicit feature that they plan for and implement. The tradeoff is that you now also need a DB call to validate the session on every request.

So, I still feel that strongly discouraging users from using a user ID isn't providing any benefits. We could expand the documentation to talk about these different strategies and their tradeoffs though. Maybe also link to the Oauth documentation which seems similar here in terms of tradeoffs of token designs: https://www.oauth.com/oauth2-servers/access-tokens/access-token-lifetime/

[toolforger]

@yanxurui the stolen login does not allow the attacker to login, they'd need a session id or a login password.

User id's are generally not considered secrets. They show up in server logs (so activities can be tracked to users), in forum posts (to allow other users to recognize postings made by the same user), in helpdesk tickets (so helpdesk persons can look up what happened).
It's the passwords, the additional factors in 2FA, the session ids which are considered secrets.

[yanxurui]

Hi @toolforger , yes your are correct that there is no risk if the login itself is leaked. However, it's a concern when the the login is used as the "identity" in this module.