Most modern, multi-user operating systems include an authorization process. This makes use of the Authentication#Computer_security process to identify consumers. When a consumer tries to use a resource, the authorization process checks that the consumer has been granted permission to use that resource. Permissions are generally defined by the computer's system administrator in some type of "security policy application", such as an access control list or a capability, on the basis of the "principle of least privilege": consumers should only be granted permissions they need to do their jobs. Older and single user operating systems often had weak or non-existent authentication and authorization systems.
"Anonymous consumers" or "guests", are consumers that have not been required to authenticate. They often have very few permissions. On a distributed system, it is often desirable to grant access without requiring a unique identity. Familiar examples of authorization tokens include keys and tickets: they grant access without proving identity.
There is the concept of "trusted" consumers. Consumers that have authenticated and are indicated as trusted are allowed unrestricted access to resources. "Partially trusted" and guests are subject to authorization for their use of protected resources. The security policy applications of some operating systems, by default, grant full access to all consumers to all resources. Others do the opposite, insisting that the administrator takes deliberate action to enable a consumer to use each resource.
Even when authorization is performed by using a combination of authentication and access control lists, the problems of maintaining the security policy data is not trivial, and often represents as much administrative burden as proving the necessary user identities. It is often desirable to remove a user's authorization: to do this with security policy application requires that the data be updateable.