BigIP APM Oauth - set to 'Failed to perform curl: Failure when receiving data from the peer'

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.

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://azure.github.io/apim-lab/apim-lab/7-security/security-7-2-3-oauth2-authorization-grant-flow.html

https://www.oauth.com/oauth2-servers/server-side-apps/authorization-code/

https://techdocs.f5.com/kb/en-us/products/big-ip_apm/manuals/product/apm-authentication-sso-13-0-0/38.html

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

🙏

probably it's content-type mismatch.

i suggest do tcpdump with ssl decryption to see more details:
tcpdump -s 0 --f5 ssl .....