people still dont understand the difference. "you do iam but what about controllong access" comes in all the time.
words dont really matter all that much. people use them because it makes them sound like they know what it is, and if its important and complex, usually have no clue.
ive seen enough "abac" where the attribute is "your login name"
ENTI- can you enter, ORI (or ORIZ) what can you do?
I don't mean to quarrel about it, but I understood Authentication to be closer to identification. To provide "adequate proof that you are actually who you claim to be".
Even the "can you enter" question falls under authorization; "does the user have appropriate permissions?" Entering is just one of perhaps many subsequent levels of permissions.
I think you've got the right idea, though in practice the initial "authentication" question (you are who you say you are) is very closely linked to the initial "authorization" evaluation (can you enter).... because in most systems the only "can you enter" authorization required for access is in fact that you are who you say you are.
But not all systems work this way. There are some systems where you can log in successfully, but then are immediately escorted out because the "can you enter" question has secondary considerations or is decided once identity has been established based on a larger criteria. Expired accounts in some systems work exactly like this.
One problem is that treating authentication as a "can you enter" authorization is predicated on the idea of a session-based system with two states, logged in or logged out. But there are many scenarios where e.g. taking some particular action requires authn and authz, regardless of login status. A simple example is performing some destructive action.
The distinction between authentication and authorization allows modeling of many different kind of systems, including the degenerate case where identification is treated as a proxy for authorization.
Btw, the kind of thinking behind that degenerate case is what leads to IDOR security bugs - "this person is logged in, so they can access whatever the URL says... even if it's another customer's data!" It turns out that thinking clearly about security helps be more secure, and unfortunately, vice versa.
Right. The de facto/apparent case that many users encounter shouldn't be considered the correct mental model or implementation pattern... it just explains why some people see it that way.
Not long ago I designed an authentication system which had to be disconnected from authorization pretty fully. The authentication was global in a multi-tenanted system, but access to any tenant was authorized at the tenant level (as well as all other authorization concerns). To be fair, there was some global authorization concerns, but the vast majority of authorizing actions, including tenant access was governed at the tenant level after authentication.
Comments
Nice!
I'd like to fix the prior abstract. Auth and auth upsets me greatly cos we have:
Authentication & Authorization
and we call both/either auth. Hence please help me make this a thing:
AuthENTIcation & AuthORIzation : ENTI & ORI
ENTI- can you enter, ORI (or ORIZ) what can you do?
This has already been solved well-enough with AuthN and AuthZ as distinct names.
UK is rotating in its decaying royal grave
I'm not opposed to AuthS either! :)
Terrible idea. Looks like a plural of auth.
I have literally never seen anyone ever use those terms and also note they both truncate to Auth.
Never change programming/maths in holding onto terrible naming conventions and making really hard stuff even harder to understand (CQRS anyone?)
people still dont understand the difference. "you do iam but what about controllong access" comes in all the time.
words dont really matter all that much. people use them because it makes them sound like they know what it is, and if its important and complex, usually have no clue.
ive seen enough "abac" where the attribute is "your login name"
Sign in / Sign up is my go to pet peeve for this type of thing
I don't mean to quarrel about it, but I understood Authentication to be closer to identification. To provide "adequate proof that you are actually who you claim to be".
Even the "can you enter" question falls under authorization; "does the user have appropriate permissions?" Entering is just one of perhaps many subsequent levels of permissions.
I think you've got the right idea, though in practice the initial "authentication" question (you are who you say you are) is very closely linked to the initial "authorization" evaluation (can you enter).... because in most systems the only "can you enter" authorization required for access is in fact that you are who you say you are.
But not all systems work this way. There are some systems where you can log in successfully, but then are immediately escorted out because the "can you enter" question has secondary considerations or is decided once identity has been established based on a larger criteria. Expired accounts in some systems work exactly like this.
One problem is that treating authentication as a "can you enter" authorization is predicated on the idea of a session-based system with two states, logged in or logged out. But there are many scenarios where e.g. taking some particular action requires authn and authz, regardless of login status. A simple example is performing some destructive action.
The distinction between authentication and authorization allows modeling of many different kind of systems, including the degenerate case where identification is treated as a proxy for authorization.
Btw, the kind of thinking behind that degenerate case is what leads to IDOR security bugs - "this person is logged in, so they can access whatever the URL says... even if it's another customer's data!" It turns out that thinking clearly about security helps be more secure, and unfortunately, vice versa.
Right. The de facto/apparent case that many users encounter shouldn't be considered the correct mental model or implementation pattern... it just explains why some people see it that way.
Not long ago I designed an authentication system which had to be disconnected from authorization pretty fully. The authentication was global in a multi-tenanted system, but access to any tenant was authorized at the tenant level (as well as all other authorization concerns). To be fair, there was some global authorization concerns, but the vast majority of authorizing actions, including tenant access was governed at the tenant level after authentication.
You're correct.
ENTIC and ORIZ would make more orthographic sense...
or 4entic5 and 4oriz5, inverting the k8s, i18n pattern...
pronounced "forentics" and "forizes"...
somebody stop me!
ident and perms
This. It's concise and I don't have to think about "which Auth" we're talking about.
magic, this is the ticket. Two totally different words.