OTP token for QuickSight's internal users

Is there the possibility to use an OTP token for users created within Quicksight (not IAM, external AD users, or external IdP auth) - normal email/password users created within Quicksight.

I do not see the option to enable OTP (via email or OTP device) anywhere - but have this compliance requirement for 2 factor authentication. What are my options?

edit: also found this Coming March 2022: An updated Amazon QuickSight sign-in experience | AWS Big Data Blog Can someone please clarify whether after this change it will be possible to use OTP for native QuickSight users?


We don’t have OTP support for native users. That would need to rely on external IdP for the time being. The new signin experience does not change the functionalities.

Is there any plan to support this in the future :pray: ?

Also, if I use AWS SSO as an IdP, then does QuickSight support SP initiated federated auth to AWS SSO?

We don’t currently have plans to support this on the roadmap, but I’ll make sure the team gets this feedback.

For AWS SSO we do support similar to how other IdP work with IAM federation. We have it on our roadmap to have a tighter integration with AWS SSO. This blog post goes over how to do it for Okta and it would be similar for AWS SSO: Federate Amazon QuickSight access with Okta | AWS Big Data Blog

Thanks for the information @lillie. My question regarding AWS SSO is mainly due to this comment in the instructions from AWS SSO to set up QuickSight as an application

Amazon QuickSight does not support SP initiated SSO.
AWS Single Sign-On (AWS SSO) Integration Guide for Amazon QuickSight

(I have not tried this yet so do not know if it is just inaccurate documentation)

However, also here Setting up service provider–initiated federation with Amazon QuickSight Enterprise edition - Amazon QuickSight there AWS SSO is missing in the SP to IdP list.

It would be strange that SP to IdP auth supports external providers (Okta, Google, Microsoft etc) but does not support SP to IdP using AWS’s internal AWS SSO service.

Makes sense. Looks like this document needs to be updated. Thanks for pointing this out