Authentication (often abbreviated as AuthN) is typically what people think of when they hear 'auth'. Authentication is the act of validating the identity of an entity (typically a user or a machine) attempting to access a system. In other words, authentication is about determining who (or what) is attempting to access a system to figure out whether to grant or deny that entity access to the system.
A basic example of authentication is username/email + password login on web applications. A user that wants to login to their account must provide their email and unique password (hopefully known only to them) which an application server can then verify against what is stored in the system, granting the user access only if the passwords match. Authentication is typically the first interaction users take within a 'gated' system and so it functions as the most basic and widespread security mechanism found within software applications.
There are many types of authentication in use today given the many available identity providers. As mentioned earlier, email/username + password is typically the most basic type of authentication used in applications. Other, user-focused authn types include multi-factor (MFA), single sign-on (SSO) via an identity provider (IdP), biometrics, QR codes and even short-lived 'magic links' and one-time passcodes (OTP) sent via email or SMS. Authentication also isn't only limited to verifying user identity. Token-based authentication is a popular form of application-to-application or machine-to-machine authentication used to verify interactions between applications and machines.
Let's take a deeper look at these common types of authentication:
One of the most popular and most widely used forms of authn. Users are identified by their unique username (sometimes email) and authenticated via a password. Passwords must be hashed and stored within the application or another service for comparison which makes them a target for attacks.
Multi-factor authentication involves the usage of multiple authn methods to authenticate a user, often implemented as basic username and password + one-time passcode (OTP). For example, an application with MFA enabled will require users to present a token sent to their email or via SMS in addition to their password. This additional step is designed to protect users in the event that their password has been compromised. The malicious party might be able to present the correct password but will not be authenticated into the account without access to the user's phone (for SMS) and/or email account.
Most medium to large businesses that use software applications and SaaS use an identity provider to manage their employee data. An identity provider is a central service that stores employee identities and has the ability to verify them. This provides a variety of benefits to employers, employees and software vendors. From an employer's perspective, an IdP provides an easier way to centrally manage employee access to applications and prevent employees from creating multiple username/password combinations (or worse share them) across applications. From the employee perspective, IdPs make it easy to sign into multiple applications with one username/password (SSO). From a software vendor's perspective, integrating with IdPs and providing SSO makes for easier adoption and a better security posture, but requires additional upfront work to integrate with all the various IdPs.
Biometrics is a newer form of authentication gaining wider adoption with the advent of new hardware, particularly fingerprint and face scanners available on laptops and phones. Hardware sensors on these devices make it easy to capture and store a user's biometrics data locally and use it to authenticate actions and access to data and applications. Perhaps the most widely used implementation of biometrics-based authentication is Apple's Touch ID and later, Face ID, found on iOS and Mac devices.
QR codes can be used as a quick but 'weak' form of authentication. As an example, a protected link can be encoded into a QR code shared with a trusted party. This ensures that only the trusted party can access the link. However, it's considered 'weak' as the QR code and subsequent link can be shared with others and exploited without proper safeguards (i.e. time-based invalidation, single-use links etc). As such, QR codes should be used sparingly (if at all) for authn.
One-time passcodes (OTP) are typically used in conjunction with username/password authn to enable multi-factor authn but can also be used as a primary authn scheme. For example, a consumer application can send a SMS to a user's cellphone containing a unique code that when entered by the user into the application, grants them access to their account. This OTP authn works assuming the user is the only one with access to the SMS. Magic links are similar to OTP and rely on the fact that the user is in control of their email and phone and will be the only one to receive a 'magic link' that automatically logs them into their account.
Tokens are often used to authenticate machine-to-machine and application-to-application interactions. One common example is API keys which can be uniquely generated and granted to users/applications to enable programmatic access to a system. There are multiple ways to generate, manage and verify these types of tokens or keys, but regardless of the algorithm or scheme used to generate them, only the issuer should have the ability to mint new tokens and verify existing tokens for access.
If you're building an application, especially SaaS or B2B software, authentication will likely be one of the first things you need to implement. Typically, your choices are to either build it in-house or use a 3rd party library or vendor.
By building it yourself, you control the implementation, your data and your users. But unless you're an expert in the authn schemes mentioned above, this option will take more time to implement and manage and will likely be harder to secure.
Going with a 3rd party library or service should reduce up front implementation and overall maintenance time and cost. It should also give you support for more authn methods 'out of the box' and a good security posture, assuming the vendor is up to date with their security. However, it will make your application (and business) rely on a 3rd party for a critical piece of infrastructure and data so it's important to thoroughly evaluate a product and vendor prior to selecting it for use in your system.
Authentication is only half of the 'auth' equation. Once a system authenticates a user or entity, the next step is to figure out what that user or entity can do or has access to within the system. Very quickly this can evolve into roles, permissions and even granular object or resource-based access control, all of which fall under the umbrella of authorization (authz).