Configuring reauthentication

IAP reauthentication allows resource owners or Google Cloud administrators to require authenticated end users to reauthenticate before accessing a resource protected by IAP.

Managing the reauthentication settings

You can use the following methods to manage the reauthentication settings:

  • Login: Mimics the behavior of a user having logged out and attempted to log in again. In most cases, end users will be required to reenter their password.
  • Password: The end user is asked to reenter their password.
  • Secure key: The end user is asked to touch their security key.

For more information, see IapSettings.

Setting a reauthentication policy

ReauthSettings are a part of IapSettings, and as such can be set on multiple resource types in the hierarchy. Unlike other IAP settings, where the lowest resource in the hierarchy takes precedence, the effective reauthentiction setting also depends on the policy type.

There are two policy types that you can use to set reauthentication:

  • Minimum: The policy will act as a minimum to all other resources down the hierarchy. The effective policy can be the same or more strict.
  • Default: If no other policy is set on the resource, the reauthentication policy you set becomes the effective policy.

You can use the policy type configuration to set policies for an entire organization or a folder by setting the policy type to Minimum.

In cases of hierarchical configurations with different reauthentication methods, Password and Secure Key turn into a Login method.

Example: In the following folder and resource IapSettings examples, the folder policy is more strict and takes precedence, so the effective reauthentication policy will match the folder policy.

Folder IapSettings:

accessSettings:
  reauthSettings:
    method: 2  # Password
    maxAge:
      seconds: 3600  # 1 hour
    policyType: 1  # Minimum

Resource IapSettings:

accessSettings:
  reauthSettings:
    method: 2  # Password
    maxAge:
      seconds: 7200  # 2 hours  
    policyType: 1  # Minimum

MaxAge

Use the MaxAge parameter to specify how often an end user must reauthenticate, denoted in seconds. For example, to set a one hour reauthentication policy, set seconds to 3600, as shown in the following example:

accessSettings:
  reauthSettings:
    method: 2  # Password
    maxAge:
      seconds: 3600  # 1 hour 
    policyType: 1  # Minimum

Understanding reauthentication credentials

After a successful reauthentication, IAP creates a cookie on the end user`s browser. To prevent users from having to reauthenticate too often when using similar apps, the cookie is set on the top level private domain and is valid for that entire private level domain.

For example, foo.example.com is an IAP protected resource and has an IAP reauthentication policy. After a successful reauthentication, IAP will set a cookie on example.com as that is the top level private domain. Apps from the same top level private domain, such as bar.example.come would use the same reauthentication credentials and would not prompt the user to reauthenticate (as long as the credentials are valid).

Note that for URLs such as myapp.appspot.com, appspot.com is a public domain, therefore the top level private domain is myapp.appspot.com.

Known limitations

  • Reauthentication is only supported for browser flows. Programmatic user account access is not supported. For example, mobile and desktop apps have no way of reauthenticating users, because resources that require reauthentication are inaccessible.
  • Service accounts and IAP-TCP are exempt from reauthentication requirements.
  • Reauthentication does not work with the IAM member type allUsers.
  • If using an identity provider other than Google, reauthentication might not work as expected.
  • External identities via Identity Platform are not supported with reauthentication, because resources that require reauthentication are not accessible.