OAuth2 Not Working with https schema on BaseURL

[AndressRod]

Hello Everyone. I'm facing an issue with openam 15.1.3. I configured the OpenAM with a domain http://auth.com:30009 (k8s port). And then, I configured on Realms > Services > Base URL Source the following domain: https://sso-example.com:443.

Everything is working fine, except OAuth2 flow. When I changed the Base URL to https, I'm getting a bad_request error on oauth/authorize endpoint. I saw the access_log from /usr/openam/config/sso/logs and I found that openam is trying to make the request over http instead of https:

0d5e766b-22a9-44b0-aedc-071e4ac7d30e-3009";"2025-03-12T04:46:32.588Z";"AM-ACCESS-OUTCOME";"0d5e766b-22a9-44b0-aedc-071e4ac7d30e-3007";"id=amadmin,ou=user,dc=openam,dc=openidentityplatform,dc=org";"[""6b7fadb766591be701""]";"172.20.117.114";"8080";"172.20.116.126";"34242";;;;"false";"POST";"**http://sso-example.com/sso/oauth2/authorize**";"{""response_type"":[""code""],""client_id"":[""creatio""],""scope"":[""oauth2basic""]}";"{""accept"":[""text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7""],""host"":[""sso-example.com""],""origin"":[""https://sso-example.com""],""referer"":[""https://sso-example.com/sso/oauth2/authorize?response_type=code&client_id=creatio&scope=oauth2basic&redirect_uri=https%3A%2F%2Foauth.pstmn.io%2Fv1%2Fcallback""],""sec-ch-ua"":[""\""Not(A:Brand\"";v=\""99\"", ""Google Chrome"";v=""133"", ""Chromium"";v=""133""""],""sec-ch-ua-mobile"":[""?0""],""sec-ch-ua-platform"":[""""Windows""""],""sec-fetch-dest"":[""document""],""sec-fetch-mode"":[""navigate""],""sec-fetch-site"":[""same-origin""],""sec-fetch-user"":[""?1""],""upgrade-insecure-requests"":[""1""],""user-agent"":[""Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36""],""x-forwarded-for"":[""172.18.1.71""],""x-forwarded-host"":[""sso-example.com:443""],""x-forwarded-proto"":[""https""],""x-real-ip"":[""172.18.1.71""]}";"{""JSESSIONID"":""218EEAE009616AB53C58909B173EA793"",""rl_page_init_referrer"":""RudderEncrypt%3AU2FsdGVkX1%2BlVc6waswpYGaKnpTCiw54si9OiTV2TbU%3D"",""rl_page_init_referring_domain"":""RudderEncrypt%3AU2FsdGVkX1%2BYAGLORCy%2F47XZs8foF2JR2QfmybWBtBU%3D"",""_ga"":""GA1.1.986866775.1726236599"",""_ga_90NZPH5QM7"":""GS1.1.1726627470.4.0.1726627822.0.0.0"",""cf_clearance"":""mfMqh6xL24OlYPcddQg.w7j4Bu3LtWPbz7ZdxRhEVpk-1737741377-1.2.1.1-RTmV4vjTznqTaLlc6b3f_ASXpH.x5cSitOv3Ww1zYZYWPHV8FClGAWiKV6dJOQWCzU8HUJZTB0jNIJYV7_C8lcwrR4ju07uAqU6SVs3LbLtw38xssEJ6fLdQRGRrflHHl6JRSszCJsSB2O0y_oJ0UengXgDeS0P5S.kndS9NFyxLl.Ml0qMrcGX52Hsy8jsqw6NDfClSci9FyyYhZQUFbD_kWxJAx2Yf1EFBLKTeRNh4.wDWEJGm__AoXaUU1LgY818Nj4i5oZM7NIzdz2_VJX3gvNxjZdfONUWJcKE9fek"",""rl_anonymous_id"":""RudderEncrypt%3AU2FsdGVkX1%2BbYpyEWr6DpcQO76Ff%2FWnPpUljXCohp%2F0k6Pl%2FpEVHXoVEC%2FDBhUTBpqbIrsPWjDnJhQR0zKveLA%3D%3D"",""rl_user_id"":""RudderEncrypt%3AU2FsdGVkX1%2B2djuiUeB%2BP98QUHwL4Hm37KcwM4tZBqf1sh5rB8N%2BsnKvwb5OONN3dcYT545UeaCI9QI%2BNRtIPGvrjXpl1oItYk6yjpzaOHQo9AJ4qNiUm3WY6Cbhzrys50PKOhOuSdEsPFnt5f4qDWCyeNmzfqsqcLuVw7kWSCU%3D"",""rl_trait"":""RudderEncrypt%3AU2FsdGVkX1%2BSfMuWas27eqZ7qIn4FywTrtAqkjc%2Bakzkx67mma1KyVfWA4lvc6TepqqppbRSMtclNOU7TQdTyEyzvxWXNdmxgmHVFeY3rHBtYNhQQadpA46t0hGs0ju1HVDO2ekIIs4HTSuMCSk4mQ%3D%3D"",""rl_session"":""RudderEncrypt%3AU2FsdGVkX1%2BPTjLUQqNWKNdwVM9Y83Y7kfbzysgavYnu1eZQJUTceWCUex1X3W16XrVUC3fjNGtNDUUvEZ5wmFaselBEZ7ankW2Xt%2FEGM7DBv%2Bn%2BOhSWlYYekl5%2F5oHR9gjGG6ZGad0YW0cJ8Qf3HQ%3D%3D"",""ph_phc_4URIAm1uYfJO7j8kWSe0J8lc8IqnstRLS7Jx8NcakHo_posthog"":""%7B%22distinct_id%22%3A%2287101d9ea65033de779058dc2860ceb410b203d6b7226e0a7d84591272eb64f9%23acc6c6df-8961-4c4a-9135-bbf141b3f119%22%2C%22%24sesid%22%3A%5B1740603597440%2C%220195440f-2280-7dde-9efb-a1dc803f76a1%22%2C1740603597440%5D%2C%22%24epp%22%3Atrue%2C%22%24initial_person_info%22%3A%7B%22r%22%3A%22%24direct%22%2C%22u%22%3A%22https%3A%2F%2Fn8n.gyt.com.gt%2Fworkflow%2Fnew%22%7D%7D"",""PROXY_URL"":""https://sso-example.com:443/sso/oauth2c/OAuthProxy.jsp"",""amlbcookie"":""01"",""iPlanetDirectoryPro"":""AQIC5wM2LY4SfcxuyWSTigCJ_bMlHItWm2d7Auivc3wnyIU.*AAJTSQACMDMAAlNLAAstMTgxMDE3NDIzMAACUzEAAjAx*"",""ORIG_URL"":""/sso?realm=%2F&goto=http%3A%2F%2Fsso-example.com%2Fsso%2Fbase%2FAMAdminFrame&service=GoogleSocialAuthenticationService&authIndexType=service&authIndexValue=GoogleSocialAuthenticationService"",""NTID"":""sRGCEcbKVke3XWGjzvq0B55ip5JCrEzq"",""i18next"":""es-419""}";;"FAILED";"400";"{""reason"":""The request could not be understood by the server due to malformed syntax""}";"3";"MILLISECONDS";"OAuth";"/"

If I try to make a request over http, everything works with no issues. Can you please tell me if I'm missing something on the configuration? I also checked the Configure > Authentication > OAuth 2.0 properties and URL Proxy is configured correctly over https.

[maximthomas]

Hi @AndressRod
You should add https://sso-example.com:443/sso to the Deployments -> Sites settings. Also check if the sso-example.com exists in the realm aliases domain (Realms -> <Your realm> -> Properties button)
More details in the documentation: https://doc.openidentityplatform.org/openam/install-guide/chap-install-multiple#configure-sites

[AndressRod]

Hi @maximthomas.

Thank you for your response. In addition to the settings mentioned above, I have the domain configured as a Site and attached to Deployments > Servers > General > Principal Site. Also the domain exists in Realms > Top Level Realm > Properties.

But the issue persists on OAuth2 with bad_request on Authorize endpoint

[AndressRod]

Also, these are the steps I followed to enable OAuth2.

1. Realms > Top Level Realm> Dashboard > Configure OAuth Provider > Configure OAuth 2.0: Created with default settings.
2. Realms > Top Level Realm> Authorization > Policy Sets > OAuth2 > OAuth2ProviderPolicy: Added https://sso-example.com:443/sso/oauth2/authorize?* as a Resource.
3. Configure > Authentication > OAuth 2.0: Changed URL Proxy to https://sso-example.com:443/sso/oauth2c/OAuthProxy.jsp
4. Realms > Top Level Realm>Applications > OAuth 2.0 > Agent: Created an OAuth agent with
   • Redirection URI: https://oauthdebugger.com/debug
   • Scope: oauth2basic
   • Response Types: Default values
   • Token Endpoint Authentication Method: client_secret_basic
   • Subject Type: Public
   • ID Token Signing Algorithm: RS256
   • Public Key Selector: X509

[vharseko]

check Add RemoteIpValve to the server.xml

[AndressRod]

Hi @vharseko.

Added the valve to server.xml and now the schema is correctly set to https:

But, the issue persists.

I realized that, if I make the request in postman with http schema this is the result:

But, if I try to make the same request with https schema this is the result:

[maximthomas]

Hi @AndressRod
Please, archive and attach /usr/openam/config/sso/debug logs to the discussion.

[AndressRod]

Sure. Thanks.
TAR: sso-logs.tar.gz
ZIP: sso-logs.zip

[maximthomas]

Hi @AndressRod
There is an event in the CoreSystem log:

org.forgerock.audit.handlers.csv.CsvFormatter:03/13/2025 09:24:53:535 AM CST: Thread[#189,http-nio-8080-exec-9,5,main]: TransactionId[03dad487-4ec3-4b7c-b5bd-cca9dd198e51-1769]
Formatted event: "03dad487-4ec3-4b7c-b5bd-cca9dd198e51-1771";"2025-03-13T15:24:53.534Z";"AM-ACCESS-OUTCOME";"03dad487-4ec3-4b7c-b5bd-cca9dd198e51-1769";"id=amadmin,ou=user,dc=openam,dc=openidentityplatform,dc=org";"[""6b5c9615bb0ebf4f01""]";"172.20.116.28";"8080";"172.18.1.71";"8182";;;;"true";"POST";"https://sso-example.com/sso/oauth2/authorize";"{""client_id"":[""creatio""],""scope"":[""oauth2basic""],""response_type"":[""code""],""response_mode"":[""query""],""state"":[""9c1kbb2bdja""],""nonce"":[""6tawnyvx2x9""]}";"{""accept"":[""text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8""],""host"":[""sso-example.com""],""origin"":[""https://sso-example.com""],""priority"":[""u=0, i""],""referer"":[""https://sso-example.com/sso/oauth2/authorize?client_id=creatio&redirect_uri=https%3A%2F%2Foauthdebugger.com%2Fdebug&scope=oauth2basic&response_type=code&response_mode=query&state=9c1kbb2bdja&nonce=6tawnyvx2x9""],""sec-fetch-dest"":[""document""],""sec-fetch-mode"":[""navigate""],""sec-fetch-site"":[""same-origin""],""sec-fetch-user"":[""?1""],""upgrade-insecure-requests"":[""1""],""user-agent"":[""Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:136.0) Gecko/20100101 Firefox/136.0""],""x-forwarded-host"":[""sso-example.com:443""],""x-forwarded-proto"":[""https""],""x-real-ip"":[""172.18.1.71""]}";"{""i18next"":""es-ES"",""amlbcookie"":""01""}";;"FAILED";"400";"{""reason"":""The request could not be understood by the server due to malformed syntax""}";"33";"MILLISECONDS";"OAuth";"/"

In the OAuth2Provider log there is a correspoindig event that causes the message above:

OAuth2Provider:03/13/2025 09:24:53:513 AM CST: Thread[#189,http-nio-8080-exec-9,5,main]: TransactionId[03dad487-4ec3-4b7c-b5bd-cca9dd198e51-1769]
Session id from consent request does not match users session

As you can see, it the same time and the same request.

This message occurs only there is a mismatch between iPlanetDirectoryPro cookie value and csrf request parameter.

[AndressRod]

Thank you for the feedback @maximthomas. We changed the name of the Cookie from iPlanetDirectoryPro to iPlanetDirectoryProW from server defaults. Maybe that is causing the issue? Another question, why do you think it works with no issues when we make the call over http? csrf in OpenAM only works with https?

[vharseko]

please check in https post iPlanetDirectoryProW cookie value is equal to csrf parameter ?

[maximthomas]

You can make the OpenAM logs more verbose, reproduce the issue and attach the new logs to the discussion.

[AndressRod]

Hi @maximthomas.

I'm attaching the files.
TAR: dump.tar.gz
ZIP: dump.zip

Analyzing the results, I realized that http call is returning 200 because first it makes a GET request. The one returning that status code (it can be viewed in the har file).

So, is additional baseURL configuration necessary?

Thanks in advance for all the help

[maximthomas]

Hi @AndressRod,

So, is additional baseURL configuration necessary?

In that case, no, because the baseURL is set by the RemoteIpValve

About the logs:
In the sso-https.pcap 400 error occurs at Date: Mon, 17 Mar 2025 18:38:15 GMT

HTTP/1.1 400 
X-Frame-Options: SAMEORIGIN
Cache-Control: no-store
Date: Mon, 17 Mar 2025 18:38:17 GMT
Accept-Ranges: bytes
Server: Restlet-Framework/2.4.0
Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept

but in the OAuth2Provider file the error occurs at 03/17/2025 11:28:56:705

OAuth2Provider:03/17/2025 11:28:56:705 AM CST: Thread[#187,http-nio-8080-exec-7,5,main]: TransactionId[b15c859e-541e-4092-b2ae-b54f2281a3d5-32236]
Session id from consent request does not match users session

There is a time mismatch, so we can't be 100% sure about the cause of the issue.

[maximthomas]

Hi @AndressRod,
According to the OpenAM log, there are requests from 172.18.1.71 to 172.20.117.13.
However, the HTTP dump was taken for requests from 172.20.1.160 to 172.20.116.126.
Please attach a correct HTTP dump and logs

[maximthomas]

@AndressRod
We have reproduced the issue, working on a solution

[vharseko]

#855

[AndressRod]

Thank you so much @maximthomas @vharseko

[vharseko]

try openidentityplatform/openam:15.1.5