Modern computing systems provide various methods for user authentication. Some authentication methods include a password requirement, where the user enters his or her user identifier as well as a secret password. This is referred to as single-factor authentication. More secure authentication regimes, such as multiple-factor authentication, require, in addition to a password, a second means of verification, such as a token, smartcard, fingerprint, retinal scan, etc. For example, with smartcard authentication, a user inserts a smartcard into a smartcard reader and enters a personal identification number (PIN). When a correct PIN is entered, one or more certificates that are stored in the smartcard are used to authenticate the user.
In computing systems that access remote resources, a user may need to be authenticated each time the remote resources are accessed, requiring the user to repeatedly enter his or her credentials. As a result, for user convenience, a feature referred to as single sign-on (SSO) may be used to reduce the burden on the user by enabling user credentials to be shared between and reused by multiple applications. For example, a web browser that uses SSO may rely on a JSON Web Token (JWT) that identifies the user and stores an authentication event. The JWT can then be stored in a browser cookie for subsequent use by other applications that require a similar type of authentication. That is, a request to the authentication service on behalf of other applications executed within the same browser may include the browser cookie, enabling the authentication service to validate the JWT and verify that the user has already authenticated.
In enterprise applications, SSO is an increasingly popular feature due to trends such as Bring Your Own Device (BYOD) and Corporate-Owned Personally Enabled (COPE) devices. For example, enterprise administrators may require enforcement of specific authentication policies when a user accesses sensitive resources, such as payroll, banking, and health care. Consequently, SSO provides a convenient way for a user to enter his or her credentials once and reuse the stored credentials to access various types of sensitive resources.
However, because native mobile applications do not store tokens in a browser, the native applications cannot share authentication information in a cookie associated with a shared authentication service. Accordingly, one common mobile SSO approach is token sharing. Token sharing occurs when one native application obtains a token from an authentication service (AS) and then shares that token with other mobile applications. Because the token is shared, the token works only in the situation where all applications are owned by one enterprise resource server. Additionally, because the AS does not know which application submitted the token to access the resource server, the AS cannot revoke the token to prevent only that application from accessing resources, since doing so would block all applications.
Further, in some circumstances, even if the user has already been authenticated to the SSO system, accessing sensitive resources may require further authentication via a more secure authentication method, commonly referred to as step-up authentication. As a result, the user is still required to enter his or her credentials each time authentication via the more secure method is requested by an application. Moreover, after the user has provided his or her credentials to perform step-up authentication for a particular application, the user may have to re-enter those credentials (e.g., re-authenticate) to access a resource with that application each time the user's session expires.
Accordingly, there are challenges faced by system administrators when attempting to provide users with convenient and secure access to sensitive resources.