yes but it's also even more important to be precise and correct which login/permission fail to be login is at best defined as authorization + authentication b

yes but it's also even more important to be precise and correct which login/permission fail to be login is at best defined as authorization + authentication but things which are in general referred to as login but only provide authorization are not that rare (e.g. you pass a token to a client) and logins which to provide authentication but not authorization exist to (but are rare and you probably could always nitpick them out of existence) Similar the term permission is hugely overloaded due to it's wide usage in more causal most times end user facing documentation. Most times permissions are used in a more generic context, like a user having the permission to do something vs. a request made by a user being authorized to do something. I mean in the end there is no reason not to use login/permission for end-user facing documentations, causal conversations etc. This terms are "good enough" most times. But if you provide a login library or technical documentation for APIs with complex interactions between authentication and authorization then using login/permission just won't cut it. Also for AuthN,AuthZ there is no point to use auto completion and there is very very little chance to mistype them as long as you don't confused them. Luckily this kind of mistakes do not fall under the patterns dyslexia causes (especially if you do the capitalization).