Forum Discussion
BigIP APM Oauth - set to 'Failed to perform curl: Failure when receiving data from the peer'
We've been dealing with a issue when an Oath token is sent to Azure for authentication using
XXX.session.oauth.client.last.auth_redirect: login.windows.net/XXXXX/XXXX
session.oauth.client.last.auth_resule 0
We are constantly seeing the error and causing out Oath Client to be denied.
We are able to perform a "discover" in the Provider and able to "dig" to the Azure Enterprise. Our DNS Resolver is able to resolve DNS as per guide. Has anybody come across this and can point us in the right direction? The only way we can make is work is to change the APM policy to "fallback" Allow
OAuthClientToAzureAD_act_oauth_client_ag: OAuth Client: failed for server '/DC-TEST/Azure_Oauth_Server' using 'authorization_code' grant type (client_id=XXXXXXXXXXXXXXXX), error: Failed to perform curl: Failure when receiving data from the peer
Session variable 'session.oauth.client./DC-TEST/OAuthClientToAzureAD_act_oauth_client_ag.authresult' set to '0'
Session variable 'session.oauth.client./DC-TEST/OAuthClientToAzureAD_act_oauth_client_ag.errMsg' set to 'Failed to perform curl: Failure when receiving data from the peer
Session variable 'session.oauth.client.last.authresult' set to '0'
OAuthClientToAzureAD_act_oauth_client_ag:
OAuth: Request parameter 'client_secret=********'OAuthClientToAzureAD_act_oauth_client_ag: OAuth: Request parameter 'grant_type=authorization_code'
OAuthClientToAzureAD_act_oauth_client_ag: OAuth: Request parameter 'redirect_uri=https://our.test.website.com/oauth/client/redirect
OAuthClientToAzureAD_act_oauth_client_ag: OAuth: Request parameter 'code=********'
OAuthClientToAzureAD_act_oauth_client_ag: OAuth Client: failed for server '/DC-TEST/Azure_Oauth_Server' using 'authorization_code' grant type (client_id=XXXXXXXXXXXXXXX), error: Failed to perform curl: Failure when receiving data from the peer
If we change the Access Policy "fallback" to "Allow" the user is then allowed to reach the backend application but would have otherwise been denied. It seem during the Oauth Client process the token request is rejected
Previously we were seeing the error below which we resolved by making sure the DNS resolver could resolve DNS correctly.
OAuthClientToAzureAD_act_oauth_client_ag: OAuth Client: failed for server '/DC-TEST/AzureAD_Server' using 'authorization_code' grant type (client_id=d7b3f856-6053-462b-a8f3-c2820e2a4c6c), error: HTTP error 503, DNS lookup failed
- zamroni777Nacreous
probably it's content-type mismatch.
i suggest do tcpdump with ssl decryption to see more details:
tcpdump -s 0 --f5 ssl .....- southern_nordicAltocumulus
I ran a tcpdump and got the following below. I see the request being made towards Azure and see the 200 OK. Is there a way I could see if the Authorizatino token is received from Azure back to APM?
Hi Southern_Nordic,
Should you try some test policy like follows:
OAuthClientToAzureAD_act_oauth_client_ag: OAuth Client: failed for server '/DC-TEST/Azure_Oauth_Server' using 'authorization_code' grant type (client_id=XXXXXXXXXXXXXXXX), error: Failed to perform curl: Failure when receiving data from the peer
try wget . if that fails too but you can access the address from another IP/device , this probably means your IP is being blocked or filtered out by either firewall/nginx anti ddos attack . try proxy .
The token_rejected error in OAuth means that the oauth_token is unacceptable to the Service Provider. The reason for this error is unspecified, but it might mean that the token was never issued, consumed, or expired and then subsequently forgotten by the Service Provider. To solve this error, make sure you have the correct credentials for your OAuth app. Double check the client_id and client_secret to make sure they are correct and being passed correctly to the Service Provider
It's important to emphasize that the problem is rooted in the client's configuration.
Authorization server does its job flawlessly issuing codes and tokens (specifically for the client shown above, server behavior was verified using browser to obtain authorization code and Postman to exchange the code for an access token).
For some reason, the client application is not capable to complete the authorization flow. It receives an authorization code from the authorization server but fails to exchange it.
User credentials provided to the server, and it responds with the authorization code, after receiving the code authorization attempt fails and client application perform the second redirect to the authorization server.
Authorization Code Flow
In Authorization code grant type, User is challenged to prove their identity providing user credentials. Upon successful authorization, the token endpoint is used to obtain an access token. The obtained token is sent to the resource server and gets validated before sending the secured data to the client application.https://www.oauth.com/oauth2-servers/server-side-apps/authorization-code/
https://aaronparecki.com/oauth-2-simplified/#others
Both client_id and client_secret are not used in the password flow. However, as you are probably aware, OAuth2 has other flows, suited for other scenarios.Namely:
the authorization code flow used in web apps that authenticate users server side. The client_id is used in the initial redirect, the client_secret is used in the last step where the app exchanges the one time code for a token.
the client credentials flow used to authenticate applications rather than individual users.
Hope this helps
🙏
- southern_nordicAltocumulus
- southern_nordicAltocumulus
Thanks for the comprehensive response but we simply followed this F5 guide
https://my.f5.com/manage/s/article/K53313351
Could you perhaps confirm what we followed incorrectly in this guide an dif there is another guide we should use?
You mentioned
"The token_rejected error in OAuth means that the oauth_token is unacceptable to the Service Provider"
Do we have to set the correct token somewhere? Once again we simply followed the guide and created the policy as attached. We can try to run a tcpdump to confirm and will also double check the credentials (client and secret)
The test policy you suggested seems to have AD auth which we do not have the option to do. We simply want the APM to send the Oauth request to Azure AD and respond with the necessary tokens for the client to authenticate.
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com