Can a token login be inhibited from loggin in with email/pwd?

Our company built an integration of a third party SaaS and Asana. This app accesses asana through a token login, using a specific email account.

We’d like to ensure that access for this specific account is only possible through the token login, and never through direct login email/password.

Is there a way to inhibit a specific account from logging on through email/pwd?
Additionally – are the access logs for a specific account accessible, so that they can be extracted and scanned?

I don’t believe either of these are possible. @Marie or @Emily_Roman, can you weigh in?

1 Like

Yes, Enterprise customers can enable and enforce SAML logging. Alternatively, if you have a Premium/Business/Enterprise account, you can enforce “Google SSO” login.

Not at the moment I’m afraid, but this is definitely something our team is considering in the future (most likely for Enterprise users I imagine).

2 Likes

Thank you @Marie . We already use SAML for SSO login. The challenge is ensuring that the service account used for the interface can’t be used by a human. From what I understand, there is no way to prevent a human from taking control of the service account, nor to find out if this happens by examining logfiles. Is this something that could be proposed as a new feature? Thanks.

Hi @Francesco_Tiberi,

I would recommend reaching out to our support team, our security specialists will be in a better place to answer this question.

Yes absolutely, feel free to create a new thread in the #productfeedback category so other folks can upvote and support this request. On our end, we’ll make sure to keep you posted on this thread once we have an update!

1 Like

One more question related to API token security:

We are struggling to make the API access to Asana through token comply with our security guidelines.

Our company built an integration with a 3rd party SaaS, with a batch job accessing Asana API: a service account logs into Asana through token access.

Tokens are like passwords and should be refreshed regularly (they shouldn’t be hardcoded, nor read from env variables).

We didn’t find a way to refresh the service account token automatically, but only through a (repetitive) human action from the Admin GUI.

Is there a way to refresh the service account token automatically, or are there any other access method, maybe using rfc6749 Client Credentials Grant?