Introducing advanced session audit capabilities in Cloudflare One

The basis of Zero Trust is defining granular controls and authorization policies per application, user, and device. Having a system with a sufficient level of granularity to do this is crucial to meet both regulatory and security requirements. But there is a potential downside to so many controls: in order to troubleshoot user issues, an administrator has to consider a complex combination of variables across applications, user identity, and device information, which may require painstakingly sifting through logs.

We think there’s a better way — which is why, starting today, administrators can easily audit all active user sessions and associated data used by their Cloudflare One policies. This enables the best of both worlds: extremely granular controls, while maintaining an improved ability to troubleshoot and diagnose Zero Trust deployments in a single, simple control panel. Information that previously lived in a user’s browser or changed dynamically is now available to administrators without the need to bother an end user or dig into logs.

Authentication and Authorization are the two components that a Zero Trust policy evaluates before allowing a user access to a resource.

Authentication is the process of verifying the identity of a user, device, or system. Common methods of authentication include entering usernames and passwords, presenting a digital certificate, or even biometrics like a fingerprint or face scan. Multi-factor authentication (MFA) requires two or more separate methods of authentication for enhanced security, like a hardware key in combination with a password.

Authorization is the process of granting or denying access to specific resources or permissions once an entity has been successfully authenticated. It defines what the authenticated entity can and cannot do within the system.

Web applications, which we'll focus on, generally use HTTP cookies to handle both authentication and authorization.

Authentication:

1. Login: When a user logs into a web application by entering their username and password, the application verifies these credentials against its database or in an Identity Provider (IdP). Additional forms of authentication may also be applied to achieve multiple factors of authentication. If they match, the server or external security service (e.g., Cloudflare Access) considers the user authenticated.

2. Cookie/Token Creation: The server then creates a session for the user in the form of a cookie or JSON Web Token. The cookie is valid for a period of time until the user has to reauthenticate.

3. Sending and Storing Cookies: The server sends a response back to the user's browser which includes the session ID and other identifying information about the user in the cookie. The browser then stores this cookie. This cookie is used to recognize the user in their subsequent requests.

Authorization:

1. Subsequent Requests: For all subsequent requests to the web application, the user's browser automatically includes the cookie (with the session ID and other identifying information) in the request.

2. Server-side Verification: The server gets the user data from the cookie and checks if the session is valid. If it's valid, the server also retrieves the user's details and their access permissions associated with that session ID.

3. Authorization Decision: Based on the user's access permissions, the server decides whether the user is authorized to perform the requested operation or access the requested resource.

This way, the user stays authenticated (and their authorization can be checked) for all subsequent requests after logging in, until the session expires, or they log out.

In modern web applications, this session state is most commonly stored in the form of a JSON Web Token (JWT).

JWTs are used in many modern web applications, and Zero Trust Network Access (ZTNA) solutions like Cloudflare Access, for authentication and authorization. A JWT includes a payload that encodes information about the user and possibly other data, and it's signed by the server to prevent tampering. JWTs are often used in a stateless manner, meaning the server doesn't keep a copy of each JWT—it simply verifies and decodes them as they come in with requests. The stateless nature of JWTs means that you do not have to rely on a central system to handle user session management which avoids creating scalability issues as the number of users accessing a system increases.

However, this stateless nature of JWTs makes debugging JWT-based authentication tricky without getting the specific JWT from a user. Here's why:

1. Token Specificity: Each JWT is specific to a user and a session. It contains information (claims) about the user, the issuing authority, the token's issuing time, expiration time, and possibly other data. Therefore, to debug a problem, you often need the exact JWT that's causing the issue.

2. No Server-side Records: Since JWTs are stateless, the server does not store sessions by default. It can't look up past tokens or their associated state, unless it's been specifically designed to log them, which is usually not the case due to privacy and data minimization considerations.

3. Transient Issues: Problems with JWTs can be transient—they might relate to the specific moment the token was used. For instance, if a token was expired when a user tried to use it, you'd need that specific token to debug the issue.

4. Privacy and Security: JWTs can contain sensitive information, so they should be handled with care. Getting a JWT from a user might expose their personal information or security credentials to whoever is debugging the issue. In addition, if a user sends their JWT through an insecure channel to a developer or an IT help desk, it could be intercepted (Cloudflare recently released a free HAR Sanitizer to help mitigate this concern).

These factors make it difficult to troubleshoot issues with JWT based authentication without having the specific token in question.

We set out to build a better way to debug issues related to a user’s identity in Cloudflare Zero Trust without sharing JWTs or HAR files back and forth. Administrators can now view a user’s Registry Identity (used for Gateway policies) and all active Access sessions.

This session information includes the full identity evaluated by Zero Trust including IdP claims, device posture information, network context and more. We were able to build this feature without any additional load on Access’ authentication logic by leveraging Cloudflare Workers KV. At the time a user authenticates with Access, their associated identity is immediately saved into a Key/Value pair in Workers KV. This all occurs within the context of the user’s authentication event which means there is minimal latency impact or reliance on an external service.

This feature is available to all customers across all Zero Trust plans. If you would like to get started with Cloudflare Zero Trust, sign up for a free account for up to 50 users, today! Or, collaborate with Cloudflare experts to discuss SSE or SASE for your organization and tackle your Zero Trust use cases one step at a time.