IAP reauthentication

Stay organized with collections Save and categorize content based on your preferences.

IAP reauthentication allows resource owners or Google Cloud administrators to require authenticated end users to reauthenticate after a specified amount of time when accessing a resource protected by IAP. This ensures that a user who is accessing an IAP-protected resource is the same person who initially authenticated at the start of the session.

Supported reauthentication methods

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

  • Login: IAP forces reauthentication of the protected application and users must log in again.
  • Secure key: End users must reauthenticate using their configured security-key-based, two-factor authentication.

For more information, see IapSettings.

Set up 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, Secure Key turns into a Login method.

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: "LOGIN"
    maxAge: "3600s"
    policyType: "MINIMUM"

Resource IapSettings:

accessSettings:
  reauthSettings:
    method: "LOGIN"
    maxAge: "7200s"
    policyType: "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: "LOGIN"
    maxAge: "3600s"
    policyType: "MINIMUM"

The minimum value for maxAge is five minutes.

To set a reauthentication policy, complete the following steps.

Console

  1. Go to the Identity-Aware Proxy page.
    Go to the Identity-Aware Proxy page
  2. Select a project, and then select the resource on which you want to set a reauthentication policy.

  3. Open the Settings for the resource and under Reauthentication policy, select Configure reauthentication.

  4. Specify the reauthentication settings, and then click Save.

gcloud

You can set a reauthentication policy on resources and services at the organization, project, and folder level. Following are some example commands for setting a reauthentication policy.

For more information, see gcloud iap settings set.

Run the following command:

gcloud iap settings set SETTING_FILE [--folder=FOLDER --organization=ORGANIZATION --project=/PROJECT --resource-type=RESOURCE_TYPE --service=SERVICE --version=VERSION

To set a reauthentication policy on the resources within an organization, run the following command:

gcloud iap settings set SETTING_FILE --organization=ORGANIZATION

To set a reauthentication policy on the resources within a folder, run the following command:

gcloud iap settings set SETTING_FILE --folder=FOLDER

To set a reauthentication policy on all web type resources within a project, run the following command:

gcloud iap settings set SETTING_FILE --project=PROJECT --resource-type=iap-web

To set a reauthentication policy on an App Engine service within a project, run the following command:

gcloud iap settings set SETTING_FILE --project=PROJECT --resource-type=app-engine --service=SERVICE

Where SETTING_FILE is:

{
 "access_settings" : {
 "reauthSettings": {
    "method": {
    "value":  "LOGIN"
 }
    "maxAge": {
    "value":  "3600s"
 }
    "policyType": {
    "value":  "MINIMUM"
     }
  }
 }
}

Replace the following:

  • FOLDER: The folder ID.
  • ORGANIZATION: The organization ID.
  • PROJECT: The project ID.
  • RESOURCE_TYPE: The IAP resource type. Must be app-engine, iap_web, compute, organization, or folder.
  • SERVICE: The service name. This is optional when resource-type is compute or app-engine.
  • VERSION: The version name. This is not applicable for compute, and is optional when resource-type is app-engine.

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 sets 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 use the same reauthentication credentials and do 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.