When it comes to managing digital identities, security is of paramount importance: no organization wants to collect personal information from users only to have that information fall into the hands of hackers and crackers. If you’ve ever wondered why you have to enter a username and password and specify your mother’s maiden name and respond to a text message sent to your cell phone and pick out all the pictures that include a bicycle, well, now you know: it’s all part of an effort to keep your digital identity safe and secure.

So does more security mean better security (and, as a result, does this added security increase your user satisfaction rates)? Well …. Although users appreciate security when it comes to, say, their bank accounts or their medical records, that appreciation level begins to drop when they have to specify the name of their childhood pet just to browse the items on an ecommerce site. In fact, a few years ago a team from the National Institute of Standards and Testing (NIST) coined the phrase “security fatigue” to refer to:

The psychological state one reaches when security decisions become too numerous and/or too complex, inhibiting good security practices, exhibited by attributes such as weariness, hopelessness, frustration, and devaluation on the part of the sufferer.

In other words, security is good, but you can have too much of a good thing. For Customer Identity and Access Management products such as the ​Akamai​ Identity Cloud, the trick is to try and balance security with a smooth and unobtrusive user experience. For example, suppose you have an ecommerce site. In that case, you might want to:

• Require no authentication to browse the items available from the site.

• Require a simple login (e.g., a username and password) to allow users to add selected items to their shopping carts. To help streamline the process, these logins can even be made “sticky;” that is, after a user has been authenticated their login session can be set for an extended period of time (say, 30 days). Unless they log out or otherwise end this session, the user can return to the site at any time within the next 30 days and add items to their shopping cart, all without having to log in again.

• Require an additional authentication factor (such as entering a code sent via text message) only when the user is ready to check out and submit their order.

Which simply means:

• A low risk activity (like browsing the site) requires no authentication.

• A moderate risk activity (like adding items to a shopping cart) requires a moderate amount of authentication.

• A higher-risk activity (like using the account to purchase items) requires a proportionately higher level of authentication.

This approach is often referred to as “Risk-based authentication”(RBA), a methodology where the authentication required will vary depending on the risk of the associated activity. How risky is it if someone poses as Maria Fuentes while simply browsing an ecommerce site? Not very. But that isn't true for someone posing as Maria Fuentes and attempting to access her user profile. 

By introducing two new claims – the acr and the amr claims – to Hosted Login, the Identity Cloud is making it easier for applications to design customer journeys that balance security and user experience. In this documentation, we’ll explain the principles underlying risk-based authentication, and explain how to use these new claims to deploy this phase of RBA in your organization.

📘

Risk-based Authentication is an add-on to Hosted Login: it is not one of the core features automatically provided to Identity Cloud customers. See your Identity Cloud representative for more details.

How does risk-based authentication work?

We’ve already given you a basic idea of what RBA does: it enables you to identify the level of authentication needed to carry out a given activity. For example, suppose that, in order to access your shopping cart and submit an order,, you need to authenticate with an email address and password and you need to complete two-factor authentication. That’s good to know. But how exactly does Hosted Login do all of this?

To explain how RBA works, let’s start by defining the two new Identity Cloud claims: acr and amr.

📘

Yes, these claims are new to the Identity Cloud, but they’ve been part of the OIDC standard for several years now. If you’ve worked with the acr and amr claims elsewhere then you should already have a pretty good idea of what they are and how they work. Adhering closely to OAuth and OpenID Connect (OIDC) standards is what Hosted Login is all about.

The acr claim in the identity token

The acronym acr is short for Authentication Context Class Reference, and, this case, refers to the acr claim that’s added to the identity token; for example, if you’re using RBA then your identity token might include a claim that looks like this:

"acr": 2

This claim can be considered your authentication “score” and, like many scores, the higher the better. The values assigned to an acr claim are based on a methodology spelled out in the NIST’s Digital Identity Guidelines (NIST Special Publication 800-63-3). Using those guidelines, the Identity Cloud calculates an acr value like this:

• As a general rule, users start with an acr score of 0.

• If a user authenticates by using an email address and password, the acr value is incremented by 1. That means that, if a user is successfully authenticated by entering an email address and password, the user will have an acr of 1: a starting value of 0 plus the 1 added to their score following the successful login.

  In other words:

  

• If a user employs either SMS or email to complete two-factor authentication, the acr value is incremented by 1. For example, suppose a user logs on to a website using an email address and password, and then completes two-factor authentication by supplying an access code sent via SMS text messaging. That user will have an acr value of 2: a starting value of 0 plus 1 from logging in with their email address and password plus 1 more from completing two-factor authentication via SMS. In other words, the user used two different authentication methods (email address/password and SMS two-factor authentication). Consequently, they end up with an acr value of 2.

That process looks something like this:

Note that a user can also get an acr value of 2 by logging on with an email address and password and then completing two-factor authentication by entering an access code sent to their email account. That adds up to an acr value of 2: a starting value of 0 plus 1 from logging in with their email address and password plus 1 from completing the two-factor authentication.

To put it a little more visually, you achieve the same acr score in two different ways:

And so, one way or another, we get an acr score of 2. The important thing is the score itself, not necessary the route you took in order to achieve that score.

But what happens now that you have this acr score? We,, as you no doubt recall, the whole idea behind risk-based authentication is that you assign an acr value to an activity; for example, you might decide that you need an acr value of 2in order to access your shopping cart and place an order. Suppose a user with an acr score of 1 tries to access their shopping cart and place an order. That’s score isn’t high enough to allow this. As a result, you can simply deny access to the cart. Alternatively, you can give the user the opportunity to increase their acr score. (In this case, by completing two-factor authentication.( Completing two-factor authentication would give the user an acr score of 2, and enable them to access their shopping cart and place their order. 

In short, users only need minimal authorization to do some activities (like browse your site). For other activities, they might need to provide an additional level of authentication. (If you walk into an airport, you don't need to provide any authentication. But if you want to go through the security line you'll need to show photo ID and a boarding pass.)

The individual acr claim levels used by Hosted Login are based on the NIST’s Authenticator Assurance Levels (AALs). These levels are described in the following table:

If we substitute the AAL levels into one of our preceding flow diagrams, we get something similar to this:

The acr_values parameter

The acr claim you see in the identity token tells you the user's authorization level: if you see an Identity Cloud acr value of 2 you know that the user logged in with an email address and password and then completed two-factor authentication. This lets you know the user’s current authentication status.

But why did the user authenticate by logging on with an email address and password and then completing two-factor authentication? Why didn’t he or she just log on with an email address and password and be done with it?

One reason for this might be the type of authentication specifically asked for in the user’s authorization request. By including the acr_values parameter in the authorization request, you can specify the exact level of authentication the user should have in order to log on. For example, here we’re requesting that the user authenticate by using an email address and password and then go through two-factor authentication (assurance level urn:akamai-ic:nist:800-63-3:aal:2):

acr_values=urn:akamai-ic:nist:800-63-3:aal:2

In turn, Hosted Login will require the user to sign on with their email address and password, and then initiate the two-factor authentication process. That’s currently the only way to reach the urn:akamai-ic:nist:800-63-3:aal:2).

There’s nothing very complicated about the acr_values parameter: as long as you know the allowed assurance levels you can use that parameter in your authorization requests. Just keep in mind that all the claims referenced by this parameter are “voluntary.” That means that these claims are considered nice to have, but aren’t required: Hosted Login will try to provide the requested authorization level, but that level is not guaranteed. You can ask for assurance level urn:akamai-ic:nist:800-63-3:aal:2 but you won't always get it. (Most of the time you will but, like we said, that's not guaranteed.)

The amr claim

The acr value reports your authorization score: for example, the acr claim might report that you’ve reached the urn:akamai-ic:nist:800-63-3:aal:2 level. However, what the acr value doesn’t tell you is how you achieved that score. Instead, the how part is left to the amr claim, a claim added to the identity token. The amr claim lists the actual procedures someone used when authenticating. Currently-allowed procedures (and their corresponding amr value) include:

• pwd. The user authenticated by using an email address and password.
• sms. The user completed two-factor authentication by using SMS.
• email. The user completed two-factor authentication by using email.
• mfa. The user completed two-factor authentication. At the moment, this means the user completed 2FA by using SMS or email. In the future, there could be other ways to complete 2FA.
• rba. The user completed risk-based authentication.

For example, suppose a user logs on by using their email address and password. In the identity token, the amr claim will be a JSON array of strings that looks like this:

"amr": ["pwd"]

If the user logs on with an email address and password and then completes two-factor authentication by using SMS, their amr claim will look like this:

"amr": ["pwd", "sms", "mfa"]

And a user who went through risk-based authentication and, as a result, had to go through 2FA will have an amr claim like this one:

"amr": ["pwd", "sms", "mfa", "rba"]

Keep in mind that even though four authentication-related items are included in the preceding amr value, this user still has an acr score of 2. That's because there are only two authentication methods -- pwd and sms -- listed in the value. The other two items (mfa and rba) aren't methods employed by the user to authenticate. Instead, they're simply reasons that help explain why the user authenticated the way they did.