Authn is short for authentication, and authz is short for authorization. These are two separate but closely intertwined concepts in the world of identity and access management (IAM).
Nach Lektüre dieses Artikels können Sie Folgendes:
Link zum Artikel kopieren
In information security, authentication (abbreviated as authn) and authorization (authz) are related but separate concepts. Both are an important part of identity and access management (IAM).
How are authn and authz different? To put it simply, authn has to do with identity, or who someone is, while authz has to do with permissions, or what someone is allowed to do.
Authentication means making sure that a person or device is who (or what) they claim to be. A person picking up tickets for an event might be asked to show their ID card to verify their identity; similarly, an application or database may want to make sure that a user is legitimate by checking their identity. Authentication ensures that data is not exposed to the wrong person.
Username and password combination
One of the most common methods for authentication is prompting a user to enter their username and password. When Jessica loads her email account in her browser, the email service does not know who she is yet — but once she enters her username and password in the login form, the service is able to check those credentials, authenticate her as Jessica, and log her in to her account.
While most people are familiar with this type of authentication, usernames and passwords can be used for more than just authenticating users. API endpoints can be authenticated in this fashion, for example.
Multi-factor authentication (MFA)
The problem with username-password authentication is that passwords can often be guessed or stolen by malicious parties. Requiring additional factors of authentication increases security for users; this concept is called multi-factor authentication (MFA). When MFA is used, an attacker needs more than a password to falsely authenticate as a legitimate user.
MFA is most often implemented as two-factor authentication (2FA). Today many services implement 2FA by asking users to prove they have a token they were issued. There are two types of tokens: "soft" tokens, like a code sent to a user via SMS or through a mobile app, and "hard" tokens, like USB keys. 2FA and MFA can also use biometric authentication factors (described below).
Public key certificate
Public key authentication is slightly more complex than these other forms of authentication, but when implemented properly, it can be more secure. It uses public key encryption to verify whether or not the authenticated party has the right private key.
(See How does public key encryption work? to learn how public keys and private keys work.)
The most common usage of public key authentication is in Transport Layer Security (TLS), in which it is used to authenticate a web server. User devices perform this type of authentication every time they load a website that uses HTTPS.
Public key authentication is also used for mutual authentication, which is when both sides of a communication authenticate each other, instead of just a client authenticating a server or a web service authenticating a user. Internet of Things (IoT) devices and API endpoints sometimes use this type of authentication.
Only usable for authenticating humans, biometric authentication involves verifying someone's identity by checking one of their physical characteristics against a database of their known physical characteristics. Face scanning or a retina scan are examples of this type of authentication.
Authorization determines what an authenticated user can see and do. Think of what happens when a bank customer logs in to their account online. Because their identity has been authenticated, they can see their own account balance and transaction history — but they are not authorized to see anyone else's. A manager at the bank, conversely, could be authorized to see any customer's financial data.
Similarly, a person may be a legitimate employee of a business, and they may have verified their identity, but that does not mean they should have access to all of that business's files and data. An employee from outside the HR or accounting departments should not be able to see everyone's compensation, for instance.
A user's authorization level determines what they have permission to do; therefore, a common term for authorized actions is "permissions." Another term for this concept is "privileges."
Organizations use some kind of authorization solution for allowing or blocking user actions. The solution usually knows which actions to allow or to block based on who the user is; for this reason, authentication is closely intertwined with authorization. There are several different ways of determining user permissions, including the following:
In role-based access control (RBAC), every user is assigned one or more predetermined roles, and each role comes with a specified set of permissions.
In attribute-based access control (ABAC), users are assigned permissions based on their attributes or the attributes of the action they are trying to perform.
In rule-based access control (also abbreviated as RBAC), actions are allowed or denied based on a set of rules that apply to all users, irrespective of their role.
OAuth is a technical standard for passing authorization from one service to another. Often used for cloud services and web applications, OAuth enables users to authenticate on one service and then have their authorization passed to another service. Their authorization level is usually determined by an identity provider (IdP), which is a separate service.
OAuth makes possible the use of single sign-on (SSO) services, with which a user can sign in once in order to access all their cloud applications. Without the use of OAuth, a user's permissions would have to be set up separately in each application.
Cloudflare Access is an authz solution that allows or blocks user actions across on-premise, self-hosted, and SaaS applications. It integrates with any IdP for authn. Cloudflare Access also evaluates device security posture before granting access, an important feature for implementing a Zero Trust model (learn more about Zero Trust).
Über Zero Trust