Staged Authentication

Question

Would anyone happen to know the terminology for using "multi-staged authentication", where each stage grants a specific level of authorization?

The concept is that you for instance browse a web page, not identifying and authenticating and you have a Level 0 in authorization.

At some point you wish to perform an action that needs authorization, thus you authenticate with a username and a password (or an OAuth token or some such), and you now have authorization Level 1.

Now you wish to perform a privileged action, which on this particular site requires you to perform 2-factor authentication. You request the action and an authentication mechanism requests you input, which you grant and you are now at authorization Level 2.

Whether this applies to just the action or whether your authorization profile for the session now is altered for the rest of the interactions is inconsequential - to this question. (If you have a good idea as to what would be better/easier/more secure, please feel free to answer that too)

What is this "multi-staged authentication" called? Do anyone know of an actual terminology for this? I may just have failed my Google classes, but could someone throw me a valid and accepted terminology for a similar application?

-- So to add a few of the answers here that I have partly mentioned in comments: OASIS Trust Elevation and IBM Step-up authentication from the accepted answer

Answer 1

This is called step up authentication; I can't find any non-IBM references to it, but it has been discussed repeatedly in Identity Ecosystem Steering Group working group meetings. I've been less involved for the past year, but this was one of those topics that we all recognize as valuable, but not urgent. (so please, work on this, do the research and present a solution).

I thought I recalled mention of this in NIST 800-63, but I can't find it right now. Closely related to your question, is what NIST calls "multi-token authentication" where multiple independent tokens are used in tandem to achieve a higher level of assurance.

The Claimant presents token authenticators generated by two or more tokens to prove his or her identity to the Verifier. The combination of tokens is characterized by the combination of factors used by the tokens (both inherent in the manifestation of the tokens, and those used to activate the tokens). A Verifier that requires a Claimant to enter a password and use a single-factor cryptographic device is an example of multi-token authentication. The combination is considered multi-factor, since the password is something you know and the cryptographic device is something you have. NIST 800-63

If you can't find anything on step-up authentication, you might look for people who are working in multi-token authentication.

I think I've also heard this referred to as dynamic authentication, but it appears that Visa has absorbed that term for a proprietary technique, so I would discard that as a search term.

Answer 2

I've never heard of specific, generally accepted terminology for it, but it's an application of the principle of least privilege.

I've seen applications that does this calls this by various terms:

• Linux: sudo/su
• Windows: User Account Control (UAC)
• Atlassian JIRA: websudo/secure administrator session
• Github: Sudo Mode

Answer 3

In agreement to the answer by Mark C. Wallace, wanted to add another reference source that uses the terminology step-up authentication for this precise situation.

The Auth0 documentation page Step-Up Authentication refers to this and also shows a possible approach on how to solve it leveraging what's defined within the OpenID Connect specification, more specifically, the following claims:

• acr - Authentication Context Class Reference: is a string used to specify the 'class' of authentication that was performed on the current session.
• amr - Authentication Methods References: is a JSON case sensitive string list of methods that were used to authenticate the current session.
• acr_values - this is a space-separated string that specifies the acr values that have been requested to use for processing the request, with the values appearing in order of preference. This can be used to request the class of acr above when authentication is to be performed.