Auth0 Home Blog Docs

IP field in auth0 logs does not show client IP when using server api calls

logs
grants
client-metadata
ip

#1

Hello,
The IP field in the Auth0 Logs are taking the server IP instead of the client IP since all the actions performed are done through API calls from server.

To avoid this conflict, Auth0 suggested "using resource owner password from server side “(https://auth0.com/docs/api-auth/tutorials/using-resource-owner-password-from-server-side#brute-force-protection-and-server-side-apis)”. This however is not working, and it is still taking the server IP.

Is there a way to identify whether the request received has the correct ip address ? When I added console log on server side to check if the header is set in the options, it has the header property auth0-forwarded-for with client ip .

Please find attached the screenshot for the console log. In the dashboard I have also enabled brute force and Trust Token Endpoint IP Header under the OAuth tab.

Only relevant forum post i found regarding this issue is given below. Is there any solution for this :
https://auth0.com/forum/t/no-way-to-set-ip-address-to-real-ip/5206
![alt text][1]


Request for Update on Logs not showing IP passed in header
#2

Can you clarify what you mean by “it is still taking the server IP.”. Where do you see the server IP, e.g. logs (if so, which logs). Also, please ensure you have enabled the Trust Token Endpoint IP Header in your Client Settings:
https://auth0.com/docs/api-auth/tutorials/using-resource-owner-password-from-server-side


#3

I have enabled Trust Token Endpoint IP Header for my non interactive client and also enabled Brute Force Detection as mentioned in the documentation. Just to clarify, my requirement is to capture client’s IP in logs(when using server API calls). Please find attached the screenshot of the log, where the IP field has server IP instead of client IP. ![alt text][1]


#4

Thanks for clarifying. We have found the cause for this and have raised this with the engineering team. This is in our backlog to fix, however we cannot commit to an ETA at this stage.


#5

Thanks for clarifying. We have found the cause for this and have raised this with the engineering team. This is in our backlog to fix, however we cannot commit to an ETA at this stage.


#6

In the meantime, if the IP is not logged, how can we verify that “Trust Token Endpoint IP Header” is working correctly?

Is an ETA available yet for this issue?


#7

In the meantime, if the IP is not logged, how can we verify that “Trust Token Endpoint IP Header” is working correctly?

Is an ETA available yet for this issue?


#8

@prashant
I’m asking the same.

  1. When are you going to implement it?
  2. Does it says a several failure login will be trusted if it is from different auth0-forwarded-for IP? so the user will not be blocked? even though it is not appear in the log?
  3. How can it be configured in a native client?

#9