I have set auth0-forwarded-for in my application and enabled the Trust Token Endpoint IP Header option in my application.
I am setting the client’s IP in my code. But still, I couldn’t see the client’s IP in auth0 log or the user’s activity history.
There is no issue with my code implementation. I have tried with curl as well. I could see the header set in the request header. How do I validate whether the option enabled or not?
If I’m not mistaken the IP sent as part of auth0-forwarded-for will only be considered for the purpose of anomaly detection and may only surface in tenant logs for events associated with anomaly detection.
You should be able to test it, by failing credentials more than the default of 10 attempts allowed; this should result in the combination of the IP you sent in the header to be blocked, but the actual network IP from which the request was issued would not be affected.
I have tried auth0-forwarded-for with invalid credentials. as you said it blocked the user with proper message. But when I try to sign in a different user with same auth0-forwarded-for IP, still it’s allowing the user to login. then it’s still blocking user based not IP based I guess, at least for the wrong credentials.
and may only surface in tenant logs for events is that means I can’t see those IP’s ??
There are different triggers within the anomaly detection functionality; from your description you triggered this (Brute-Force Protection) for a single user so a different user from the same IP address will not be affected.
If you trigger this one (Brute-Force Protection) then the actual IP address will be blocked for some time.
In relation to your last question, from the test you performed (a user got blocked) a event log entry of type limit_wc (Logs) should have been generated. In that specific log entry I believe the IP from the header will be surfaced as that entry is specific to anomaly detection.