Asana のアクセス管理機能（SSO・MFA・IP制限・監査ログ）

Permissions in Command

Password strength and force password reset

Audit log details for failed SAML logins

SAML session timeout

Public certificate

Two-factor authentication

Who can use this feature?

StarterAdvancedEnterpriseEnterprise+PremiumBusinessLegacy Enterprise

Visit our pricing page for more information.

By default, Asana's regular authentication steps apply, and your organization members have the choice to either use a traditional password or Google SSO to log into their respective accounts.

In paid organizations, super admins can select how their members log into Asana, set password complexity requirements and force reset all members' passwords. If you purchase a division plan on Enterprise, Enterprise+, then SAML can also be enabled. SAML can also be enabled for divisions on the Legacy Enterprise tier.

Paid authentication settings only apply to your organization members. Organization guests are not affected by your authentication settings.

Like what you see? Get started with a free Asana trial today. Try for free.

Check out this article to find out how to update password strength requirements and force a password reset for your organization.

If your company uses Google Workspace for business or education, and you are using a paid version of Asana, you have the option to require your members to authenticate via Google.

You can't set up Google Sign-In if you are on a Division Plan.

To change your organization to Google Sign-In, navigate to the Security tab in the admin console. From here, go to the Global authentication settings and click Google sign-in. Select Required for all members, except guests and click Save changes.

Once this change has been saved, any passwords associated with your members' Asana accounts will no longer work and they will be required to use Google SSO.

If you are changing the email domain associated with your Google accounts, please contact us so that we can add the new domain to your organization.

If your company uses an identity provider like OneLogin, Okta, LastPass, Microsoft Entre, SecureAuth, or Active Directory, your IT department may want to configure SAML. To set up SAML, you must:

Belong to an organization or division on Asana Enterprise, Enterprise+, or Legacy Enterprise.

Once an organization has been set up with SAML, the organization members will no longer need a password to log into their accounts. From the login page, they can just enter their email and click Log in, leaving the password field empty. Alternatively, they can also use the IdP app dashboard to access Asana.

Step One: Configure your IDP

If you meet those conditions, the first step is to configure Asana with your identity provider. The steps for OneLogin, Okta, LastPass, Bitium, SecureAuth, Active Directory and Entrust Identity are listed below, but you can also do this for other identity providers:

Active Directory

Check out this document to find out how to set up SAML for Asana with Active Directory.

You could also try Okta Cloud Connect. Okta Cloud Connect is a free edition of Okta for one application. It allows you to set up Okta for AD integration and SSO for one core application. You can find more information here.

Microsoft Entra

Check out this article to find out how to set up SAML for Asana with Microsoft Entra.

Google Workspace

Learn how to set up SSO via SAML for Asana here.

In LastPass Enterprise, first go to your Enterprise Console and select the SAML tab at the top of the console. You will then be taken to the main SAML page

Follow the instructions on the screen

Copy the Log-in URL and the x.509 certificate for use in Step Two

In Okta, click the Applications tab

Search for Asana

Learn more here.

In OneLogin, go to Apps > Find apps

Click add next to Asana

Copy the the sign-in page URL and x.509 certificate somewhere for use in Step Two

Check out this article for step-by-step instructions on setting up SAML for Asana with SecureAuth.

Entrust Identity

Check out this article to find out how to set up SAML for Asana with Entrust Identity.

Step Two: Configure Asana

After you've configured Asana with your identity provider, you now make the appropriate changes in Asana.

To change your organization to SAML

Click your profile photo and select Admin console from the drop-down menu

Navigate to the Security tab

Navigate to the Global authentication settings section

Click SAML authentiction

Click Required for all members, except guest accounts

Paste the sign-in page URL that you copied from Step One into its corresponding field

Paste the X.509 Certificate that you copied from Step One into its corresponding field

Set a session timeout for your members

Add a mobile session timeout if needed

Click Save changes

All of your users will be logged out (you included) in order to guarantee that all of your full members authenticate via SAML from that moment on.

If you are using open-source or non native integrations, such as Shibboleth or PingFederate. You will need to share the Asana SSO metadata with the technical contact to be configured in their IdP of choice.

<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://app.asana.com/">

<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>

<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://app.asana.com/-/saml/consume" index="0"/>

</md:SPSSODescriptor>

</md:EntityDescriptor>

We recommend that a super admin for your organization first sets SAML to optional and tries to log in with their SAML credentials. Then after a successful login, the super admin can switch the configuration to required.

Super admins can set SAML session timeout between 1 hour and 30 days in the admin console. Members will be automatically logged out and asked to log in again after the specified timeout set.

What your client has access to in Asana Client Management

Asana Client Management pricing and plans

Integrations in Command

Command GitHub integration

Setting up Command

No articles found for this topic.

Getting started with Command

Coding agents in Command by Asana

Permissions in Command

Mandatory two-factor authentication

In This Article

What is an authentication code?

Turning on 2FA for your organization

How it works for an existing user

How it works for a new user

Who can use this feature?

EnterpriseEnterprise+

Visit our pricing page for more information.

Available on Asana Enterprise and Enterprise+ tiers, as well as legacy tier Legacy Enterprise.

Admins can enforce two-factor authentication (2FA) for all domain members and guests, enhancing security. Enabling two-factor authentication means that Asana will ask for an additional code, in addition to email and password, when authenticating. This will be useful for guests without SAML/SSO as they don't usually have an email address that belongs to the admin's organization.

Related articles

Two-factor authentication

This feature is for security-conscious admins who want to add an additional layer of security for their users/domain. Enabling 2FA as required will require 2FA for both members and guests to log in to domains that may not be SSO/SAML required. For SSO/SAML required domains, this feature enforces two-factor authentication only for guests logging in.

Asana's two-factor authentication relies on time-based one-time passwords (TOTP). These one-time numeric passwords are supported by authenticator apps such as Authy, Duo, Microsoft Authenticator, and Google Authenticator using the TOTP standard. You can find more information about TOTP authentication codes at this link. 2FA will be enforced on users logging in on the web and through the mobile app.

Like what you see? Get started with a free Asana trial today. Try for free

Admins can activate 2FA from the Security tab in the admin console. You must also activate 2FA for your own account before you can require it for your organization.

Divisional admins will need to contact Asana support to enable 2FA as required for their organization. This will affect all users, including those outside the division.

Upon activation, users (full members and guests) in your organization will receive an email asking them to enable 2FA for their account.

Asana will display a banner prompting users to set up 2FA for their account.

Users can go to their Settings to set up and enable 2FA from this email.

If your organization is set up to require SSO or SAML then full members in your organization won’t be required to set up 2FA as they are already using a secure method to login to Asana. We will still enforce 2FA for any guests logging into Asana.

Users (members or guests) in your organization who don't set up 2FA within 7 days after it is required will be logged out and will need to set up 2FA before they can log in to Asana. Additionally, if users do not set up 2FA within 14 days, their passwords will be invalidated, and they will need to reset their password via the Forgot Password flow to log in again.

You will see this screen to confirm that 2FA has been set up. Click Continue to carry on setting up your Asana account.

Can I turn on 2FA for my division?

Yes, mandatory 2FA is available for divisions on Asana Enterprise and Enterprise+, as well as legacy tier Legacy Enterprise. Division admins can request that 2FA be enabled by contacting Asana support. In this case, 2FA will be enabled for the entire domain (not just the division).

How will my users know that they need to turn on 2FA? How soon do they need to set up 2FA?

Users will receive an email asking them to set up 2FA after admins turn on 2FA. All users within the domain will be logged out after 7 days if they do not set up 2FA.

What kind of 2FA will my users be asked to set up?

The second factor for authentication will come from 3rd party authenticator apps such as Duo, Authy, or Microsoft Authenticator that can be installed on the phone.

Command GitHub integration

Setting up Command

No articles found for this topic.

Getting started with Command

Coding agents in Command by Asana

Permissions in Command

Mandatory two-factor authentication

In This Article

What is an authentication code?

Turning on 2FA for your organization

How it works for an existing user

How it works for a new user

Who can use this feature?

EnterpriseEnterprise+

Visit our pricing page for more information.

Available on Asana Enterprise and Enterprise+ tiers, as well as legacy tier Legacy Enterprise.

Admins can enforce two-factor authentication (2FA) for all domain members and guests, enhancing security. Enabling two-factor authentication means that Asana will ask for an additional code, in addition to email and password, when authenticating. This will be useful for guests without SAML/SSO as they don't usually have an email address that belongs to the admin's organization.

Related articles

Two-factor authentication

This feature is for security-conscious admins who want to add an additional layer of security for their users/domain. Enabling 2FA as required will require 2FA for both members and guests to log in to domains that may not be SSO/SAML required. For SSO/SAML required domains, this feature enforces two-factor authentication only for guests logging in.

Asana's two-factor authentication relies on time-based one-time passwords (TOTP). These one-time numeric passwords are supported by authenticator apps such as Authy, Duo, Microsoft Authenticator, and Google Authenticator using the TOTP standard. You can find more information about TOTP authentication codes at this link. 2FA will be enforced on users logging in on the web and through the mobile app.

Like what you see? Get started with a free Asana trial today. Try for free

Admins can activate 2FA from the Security tab in the admin console. You must also activate 2FA for your own account before you can require it for your organization.

Divisional admins will need to contact Asana support to enable 2FA as required for their organization. This will affect all users, including those outside the division.

Upon activation, users (full members and guests) in your organization will receive an email asking them to enable 2FA for their account.

Asana will display a banner prompting users to set up 2FA for their account.

Users can go to their Settings to set up and enable 2FA from this email.

If your organization is set up to require SSO or SAML then full members in your organization won’t be required to set up 2FA as they are already using a secure method to login to Asana. We will still enforce 2FA for any guests logging into Asana.

Users (members or guests) in your organization who don't set up 2FA within 7 days after it is required will be logged out and will need to set up 2FA before they can log in to Asana. Additionally, if users do not set up 2FA within 14 days, their passwords will be invalidated, and they will need to reset their password via the Forgot Password flow to log in again.

If 2FA is mandatory in an organization that a user belongs to, then the user will need to set up 2FA the next time they log in to Asana if they have an existing account in Asana. The instructions below show how this can be done.

As an existing user in Asana, you'll be required to set up 2FA after an admin makes 2FA mandatory. The next time you log in to Asana, you'll be asked to set up 2FA.

Go to the Google Play Store on Android or the App Store on iPhone to search for an authentication app such as Duo, Authy, or Microsoft Authenticator. Install and set up the app as directed by the app.

Scan the barcode shown, add it to your authenticator app, and click Continue.

On the next screen, enter the 6-digit code shown inside the authenticator app for this newly added Asana account and click Continue.

The next screen will confirm that 2FA has been set up for your account. Asana will ask you for your email, password, and the authentication code from your app every time you log in.

If two-factor authentication is mandatory in an organization to which a user has been invited, they will need to set up 2FA during the Asana account creation process. The instructions below show how to do this.

Continue your setup by entering your username and password on the next screen

The next step is to set up two-factor authentication for your account:

Search for an authentication app such a Duo, Authy or Google Authenticator by going to the Google Play Store on Android, or App Store on iPhone. Install and set up the app as directed.

Once installed, scan and add the QR code provided on the Asana screen or manually enter the secret key displayed on the authenticator app.

Your app will display a 6-digit code for the added account that is valid for a few seconds only. Enter this 6-digit code on the Asana page and click Enable.

You will see this screen to confirm that 2FA has been set up. Click Continue to carry on setting up your Asana account.

Can I turn on 2FA for my division?

Yes, mandatory 2FA is available for divisions on Asana Enterprise and Enterprise+, as well as legacy tier Legacy Enterprise. Division admins can request that 2FA be enabled by contacting Asana support. In this case, 2FA will be enabled for the entire domain (not just the division).

How will my users know that they need to turn on 2FA? How soon do they need to set up 2FA?

Users will receive an email asking them to set up 2FA after admins turn on 2FA. All users within the domain will be logged out after 7 days if they do not set up 2FA.

What kind of 2FA will my users be asked to set up?

The second factor for authentication will come from 3rd party authenticator apps such as Duo, Authy, or Microsoft Authenticator that can be installed on the phone.

Will members of my organization who log in via SSO/SAML need to set up 2FA as well?

Integrations in Command

Command GitHub integration

Setting up Command

No articles found for this topic.

Getting started with Command

Coding agents in Command by Asana

Permissions in Command

In This Article

Configuring IP allowlist

Managing API Access

Frequently Asked Questions

Who can use this feature?

Visit our pricing page for more information.

Available on Asana Enterprise+. Visit our pricing page for more information.

IP Allowlisting enhances your organization's security by restricting access to your Asana organization from only specified IP addresses or ranges. This ensures that only users connecting from approved networks can access your Asana organization.

Super admin configuration: Only super admins can enable or modify IP allowlisting settings. To activate this feature, the super admin must include their own IP address in the allowlist.

Customizable IP ranges: Define specific IP addresses in IPv4 or IPv6 format, or include any ranges in CIDR notation.

User-level restrictions: Apply IP restrictions to all users, only organization members, or only guests.

API Restrictions: Choose to apply IP restrictions to API traffic

To enhance your organization's security by restricting access to approved IP addresses, follow these steps:

Navigate to the admin console

Under the Security section, locate the IP Allowlisting settings

Next, define your IP allowlist settings.

Set to apply settings to all users, only members, or only guests

Name and IP address or range/s

Ensure your current IP address is included in the allowlist.

Click Save to apply the changes.

Ensure you have checked the box Enable allowlist which will start enforcing access based on the entered IP addresses or ranges.

When a user tries to access your organization on a non-approved IP they will be asked to join on an approved network.

By default, IP allowlisting applies to browser-based access only. To also restrict API traffic, you must separately enable the “Apply to API traffic” option. This setting is off by default and independent of your main allowlist toggle — enabling IP allowlisting alone does not restrict API access.

Organizations that have disabled third-party app access and only use internally managed integrations

High-security environments where all programmatic access must be network-restricted for compliance purposes

When to avoid this setting

We do not recommend enabling API traffic filtering if your organization uses cloud-hosted apps or public integrations. These services use dynamic IP addresses that change frequently and are not under your control. Enabling this setting in those environments will likely cause integrations to stop working.

If you want to restrict which apps and integrations can access your domain without relying on IP addresses, we recommend using Asana's App Management and Integrations controls. This feature provides administrators with robust tools to control and monitor third-party applications connected to their organization's Asana environment. This includes capabilities such as viewing connected apps, setting global app permissions, blocking or approving specific apps, and managing personal access tokens.

Can I use IP Allowlisting without being a super admin?

No. Only Super Admins can configure or modify IP Allowlisting settings.

Accessing audit log API endpoints

Note that only Service Accounts belonging to organizations on the Asana Enterprise+ tier, legacy tier Legacy Enterprise, or an Enterprise domain with the Compliance Management Add-on can access audit log API endpoints. Authentication with a Service Account Token is required.

Asana's audit log is an immutable log of important events in your organization's Asana instance.

The audit log API allows you to monitor and act upon important security and compliance-related changes. Organizations might use this API endpoint to:

Set up proactive alerting with a Security Information and Event Management (SIEM) tool like Splunk

Conduct reactive investigations when a security incident takes place

Visualize key domain data in aggregate to identify security trends

Note that since the API provides insight into what is happening in an Asana instance, the data is read-only. That is, there are no "write" or "update" endpoints for audit log events.

For a full list of supported events, see supported audit log events.

Globally unique identifier of the AuditLogEvent, as a string.

string (date-time)

The time the event was created.

The type of the event.

The category that this event_type belongs to.

The entity that triggered the event. Will typically be a user.

actor.actor_type

The type of actor. Can be one of user, asana, asana_support, anonymous, external_administrator, or data_retention_policy. Click to show all enum values

data_retention_policy

external_administrator

Globally unique identifier of the actor, if it is a user.

The name of the actor, if it is a user.

The email of the actor, if it is a user.

The primary object that was affected by this event.

resource.resource_type

The type of resource.

resource.resource_subtype

The subtype of resource. Most resources will not have a subtype.

Globally unique identifier of the resource.

The name of the resource.

The email of the resource, if applicable.

Event specific details. The schema will vary depending on the event_type.

details.old_value

The previous value of the field that was modified in the audited event.

details.new_value

The new value after the modification in the audited event.

The division or organizational unit where the event occurred. Primarily used to scope role change events (e.g., user_division_admin_role_changed), but may appear in other contexts involving group-level changes.

details.saml_response

The response received from the IdP when a user logs in with SAML SSO. Present on user_login_failed and user_login_succeeded events.

The context from which this event originated.

context.context_type

The type of context. Can be one of web, desktop, mobile, asana_support, asana, email, or api. Click to show all enum values

context.api_authentication_method

The authentication method used in the context of an API request. Only present if the context_type is api. Can be one of cookie, oauth, personal_access_token, or service_account. Click to show all enum values

personal_access_token

service_account

context.client_ip_address

The IP address of the client that initiated the event, if applicable.

context.user_agent

The user agent of the client that initiated the event, if applicable.

context.oauth_app_name

The name of the OAuth App that initiated the event. Only present if the api_authentication_method is oauth.

context.rule_name

The name of the automation rule that initiated the event.

context.on_behalf_of_user_id

The ID of the user who requested a change via support.

Example JSON for AuditLogEvent:

"gid": "12345",

"created_at": "2021-01-01T00:00:00.000Z",

"event_type": "task_deleted",

"event_category": "deletion",

"actor_type": "user",

"name": "Greg Sanchez",

"email": "[email protected]"

"resource_type": "task",

"resource_subtype": "milestone",

"name": "Example Task",

"email": "example string"

"old_value": "example string",

"new_value": "example string",

"saml_response": "example string"

"context_type": "web",

"api_authentication_method": "example string",

"client_ip_address": "1.1.1.1",

"user_agent": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36",

"oauth_app_name": "example string",

"rule_name": "When Task is added to this project",

"on_behalf_of_user_id": 12345

Updated 7 months ago

Audit log events

Did this page help you?