Autentikasi Multifaktor (MFA)

Multi-Factor Authentication (MFA) adds an extra layer of security to user accounts beyond just a password.

Instead of relying on a single piece of evidence (like "something you know"), MFA requires two or more verification methods from different categories.

MFA typically combines factors from these categories:

• Something you know: A password or PIN.
• Something you have: A phone, hardware token, or authenticator app.
• Something you are: A fingerprint, face scan, or voice recognition.

Using multiple factors makes it much harder for unauthorized users to gain access.

OpenID Connect (OIDC) itself doesn't perform MFA. Instead, it acts as a secure way for an Identity Provider (IdP) to tell your application whether a user authenticated with MFA.

Your application can then use this information to make informed authorization decisions.

In OIDC, "Authentication Context Class References" (ACR values) are used to specify how a user was authenticated.

These are unique identifiers that represent different levels or methods of authentication, including whether MFA was used.

When your application initiates an OIDC authorization request, it can include the acr_values parameter.

This parameter tells the Identity Provider that your application prefers or requires a specific authentication context, such as MFA.

Here's a simplified example of an OIDC authorization URL requesting an MFA context. The specific acr_values like "mfa" or "https://acr.example.com/mfa" depend on the Identity Provider's configuration.

After successful authentication, the Identity Provider returns an ID Token to your application. This token contains various claims about the user and their authentication session.

The acr claim within the ID Token indicates the actual authentication context class reference that was satisfied.

Let's imagine an ID Token payload after a user authenticated with MFA. The acr claim would be present, confirming the authentication method used.

In a real application, you would decode and validate the JWT to read this claim.

Once your application receives and validates the ID Token, it can check the acr claim.

Based on this, you can implement conditional access policies. For example, if a user tries to access sensitive data, and the acr claim doesn't indicate MFA, you might deny access or prompt for re-authentication.

We've learned that MFA adds critical security layers by requiring multiple authentication factors.

OIDC doesn't perform MFA itself, but it provides a standardized way (via acr_values in requests and the acr claim in ID Tokens) for applications to request and receive information about the authentication context, enabling robust, MFA-aware security policies.