Identifying Client IP Addresses in Okta Audit Logs

Being able to identify client IP addresses in Okta Audit Logs is essential for detecting and preventing identity-related threats. These IP addresses help establish a baseline of identity activities and highlight deviations often associated with threat actors. By monitoring and analyzing client IPs, organizations can detect unauthorized access attempts, mitigate security risks, and enhance overall identity security.

In Okta Audit Logs, different fields convey client IP address information. It can be challenging to interpret the data without understanding the specific technical details of how Okta structures its audit logs and what each field represents. 

Customers frequently ask us about our recommendations for managing client IP addresses in Okta audit logs. They often query whether it’s advisable to extract the second-to-last IP address from the chain of authentication events and consider it as the actual IP address of the client initiating the request.

In this blog post, we’ll walk through the fundamentals of the ipAddress and the ipChain. This will help you understand why using the ipAddress is advisable instead of parsing the ipChain to get the client IP.

Understanding the ipAddress and the ipChain

In the Okta audit log, two fields are relevant to the client’s IP information: the client.ipAddress field and the request.ipChain field. The ipChain is an array of IP and IPGeo information, while the ipAddress is a single IP corresponding to one of the IPs in the ipChain. 

Below, we illustrate how a client request unfolds through Okta’s network:

We’ll now explore the logic Okta’s server applies to extracting the ipAddress. 

Understanding the Client IP, the “Trusted Proxy,” and “Trusted Application”.

Okta implies in their IP Zone Evaluation document and whitepaper that the ipAddress field is determined by inspecting the ipChain (XFF header value and the last hop IP) and by extracting the first IP that is not in the “Trusted Proxy” setting.

Another Okta feature leveraging the same mechanism to verify the client IP is known as a “Trusted Application.” Okta provides an SDK for clients interested in developing their applications to broker authentication. For instance, a vault server can implement such a method to authenticate a client via Okta. In this setup, the broker server is responsible for transmitting the client IP through the XFF header. However, this transmission is acknowledged only if the broker IP is configured as a “Trusted Proxy.”

Limited Authentication Capabilities in Okta’s ipChain Create Risk 

Apart from the “Trusted Proxy” setting, Okta does not offer authentication mechanisms specifically for setting the XFF header. Consequently, any client can access Okta’s API endpoint and include a chain of IPs in the header. Okta always includes the entire list of IPs in the ipChain log field regardless of their origin.

While Okta can interpret the chain through the “Trusted Proxy” setting, it’s crucial to understand that individuals relying solely on the Okta audit log should exercise caution. Blindly following the chain without discerning its trustworthiness poses a risk. There’s potential for threat actors to manipulate the perception of the request’s origin, making it appear to come from a legitimate IP address that has circumvented identity-threat detections.

Okta doesn’t explicitly highlight this risk. In fact, some of Okta’s knowledge-base articles are ambiguous regarding whether the ipChain is the outcome of proxy pass-through.

What should I do as an audit log consumer?

If you notice multiple entries in the ipChain and suspect that the ipAddress isn’t correctly pointing to the actual client IP, instead of trying to trace and resolve it on your own, we recommend you:

• Collaborate with your IT and engineering departments to investigate the IPs in the chain. Verify the reliability of the proxy/application IP together.
• Ensure that trusted proxy/application IPs are consistently maintained within Okta’s IP Zone setting, rather than handling them in an ad-hoc manner.
• Once the aforementioned steps are completed, use the ipAddress as opposed to the ipChain to locate the legitimate client IP. 

Implementing these measures ensures more accurate data in the audit log and more precise outcomes from your identity threat detection capabilities.