Why does Zscaler recommend configuring the Authentication Frequency to be Only Once?
Zscaler offers multiple options for how often users are required to authenticate to the Zscaler service. The authentication frequency options are Daily, Only Once, Once Per Session, and Custom. For more information about these options, see What are the Authentication Frequency options?
Zscaler recommends that you choose Only Once as your authentication frequency. This is the default authentication interval. Choosing Only Once as the authentication frequency allows for a seamless experience for the end user. The Zscaler service only needs to authenticate users once to set the cookie. Once users have logged in, they do not need to authenticate again as long as the cookie is saved in the browser. (Typically, the cookie expires in about two years.) However, to log out of Zscaler, users must log out of the service explicitly or delete the cookie from their browser.
See below for answers to the questions you may have about choosing Only Once as your authentication frequency.
What if a user steals an authentication cookie and uses it to browse as another user?
Zscaler issues an authentication cookie encrypted with SSL for the gateway cloud, therefore that cookie can only be set and read from the gateway SSL site. It also cannot be sniffed on the network. When a user browses to a website, the proxy can only get cookies from that website. It issues a redirect to the gateway to fetch the cookie, and then validates it. If the gateway cookie is valid, the proxy generates a new domain cookie for that website and issues a redirect to it. Therefore the cookie, for the website to which the user browsed, provides the user identity for the Zscaler proxy. This domain cookie is rotated for every 12 hours.
If a user steals a domain cookie, that user can browse the Internet through Zscaler to that website for up to 12 hours maximum. They cannot browse to another website if they do no have the gateway SSL cookie and the cookie generation algorithm for domain cookies.
What if a user's device is stolen or a user is terminated?
If the user's device is stolen, the culprit can use it to browse the Internet through Zscaler as that user. Alternatively, if a user is terminated, but has authenticated to the Zscaler service on a personal device, then that user can browse the Internet through Zscaler. However, this is not a security issue because the Zscaler cookie does not give access to any privileged resources. The culprit may first try to disable the Zscaler traffic redirection because all of their actions on the stolen device will be logged.
AD Server Scalability and Reliability
What if my chosen authentication frequency requires users to authenticate to the service more than once?
If you choose Only Once as your authentication frequency, authentication will be completely transparent to your end users during maintenance or a downtime window of your Active Directory (AD) server. If you choose an authentication frequency that requires users to authenticate to the service more than once, your users will authenticate against your AD server on a regular basis. For example, if you choose Daily as the authentication frequency, all of your users must authenticate themselves against the AD server everyday when they access the Internet. You will have to ensure that your server can scale these requests.
What if the IT administrator adds a user, updates group information for a user, or deactivates a user?
If you choose Only Once as the authentication frequency, user and group information is only updated when synchronization is performed. If you do not synchronize the information with a directory server, you can either add and delete users manually, update the group information, or modify the group in the Zscaler admin portal.
Zscaler also exposes the API to update the information via third-party IdP vendors, such as Okta.