• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Finally, you can manage your Google Docs, uploads, and email attachments (plus Dropbox and Slack files) in one convenient place. Claim a free account, and in less than 2 minutes, Dokkio (from the makers of PBworks) can automatically organize your content for you.


Domain Specific Authentication Mode and Level

Page history last edited by Mike Schwartz 7 years, 7 months ago

Michael Schwartz, Gluu

Yuriy Movchan, Gluu

Use Case

"Adaptive authentication" requires minimal authentication, and "stepped-up" authentication for privilege escalation. The goal of adaptive authentication is to improve the security and user experience of authentication. 


Organizations are struggling to implement adaptive authentication.  They need to make the devices smart enough to request a specific type of authentication. For example, if your device has a fingerprint reader, or you have a USB security token, you need the device to request a certain type of authentication.

In the Gluu OP, we enable the domain to define multiple types of authentication. Each new type of authentication has a "name" and "level." The name is a string identifier, and the level is an integer specifying the relative strength of the authentication mechanism, as defined by the policies of that domain. 


Organizations can define internal standards for the names and relative strength of the authentications mechanism that they offer. Inter-domain, multi-party federations may also find it useful to define conventions for authentication mechanisms. 


The domain SHOULD publish the types of authentication available in the format:

"authtypes_supported": [ ["basic",10], ["certificate", 20], ["token", 25]...] 

Authentication Parameters

If a client requests a specific type of authentication using the "auth_mode" or "auth_level" parameters, the OP SHOULD accommodate the client. 



Access Token

It is useful for a host to understand the authentication strength used to obtain the access token. For this reason, the OP SHOULD persist the auth_mode and auth_level in the access token.

"auth_mode": "duo"
"auth_level": 10


How does this differ from ACR?
ACR in OpenID Connect is intended to align with ACR in SAML. Although ACR is generic, and does not require identity proofing concerns, several defined ACR's couple them, including: ISO 29115:2013,  InCommon Silver, and other National Standards like SP800-63. A complete list of SAML authn contexts are available at OASIS. "auth_mode" and "auth_level" are intended to be more agile, and may be a component of policies expressed in the ACR. 

Comments (1)

Mike Schwartz said

at 9:53 am on May 27, 2013

A similar approach for "authentication level" is used in popular Web Access Management platforms to control authentication mechanisms within a domain.

You don't have permission to comment on this page.