Comment by Quarrelsome

2 days ago

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?

16 comments

Quarrelsome

Reply
hobofan  2 days ago

This has already been solved well-enough with AuthN and AuthZ as distinct names.

  • Quarrelsome  2 days ago

    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?)

  • zobzu  2 days ago

    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"

nicwolff  2 days ago

ENTIC and ORIZ would make more orthographic sense...

or 4entic5 and 4oriz5, inverting the k8s, i18n pattern...

pronounced "forentics" and "forizes"...

somebody stop me!

lozf  2 days ago

> 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.

  • sbuttgereit  2 days ago

    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.

    • antonvs  2 days ago

      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.

      1 reply →