| This sucks... authorization and permissions are not the same thing. Permissions are rights or privileges, which exist independently of their assignment to particular users. Authorization, on the other hand, can have two meanings - both of which relate to _assignment_ of permissions to users (preferably via groups or roles): 1. The process of assigning permissions to users, as in "you need to be authorized to do that". 2. The process of confirming whether a user has the necessary permissions to perform some action. The second meaning can also be referred to as access control (or more precisely, runtime access control). It's what applications typically do after authenticating users. Hence, if you want an alternative to "authorization" in the runtime verification sense, the term "access control" might be appropriate. On the other hand authN and authZ are perfectly adequate and well-understood. Since the term "authorization" always relates to a (direct or indirect) binding between permissions and users, it makes no sense to use the term "permissions" as a substitute for "authorization". |
Here "permission" is defined as an "Operation/Object pair" - for example, read/write/execute access to a particular file. But crucially, there's no user involved (yet). That's where authorization comes in. When a permission becomes associated with a user (in this case via roles), you have authorization.
This sense of the word "permission" has now become very well established in the field of identity and access control.