IBM Security Verify

 View Only
  • 1.  OAuth Authorization code flow -- token endpoint problem

    Posted Thu November 12, 2020 03:24 PM
    Edited by Louis Beaudry Thu November 12, 2020 03:24 PM
    Hi community,

    We have an OAuth Authorization code flow.

    The AAC component is at ISVA 10.0.0.1
    The Reverse Proxy component is at ISVA 9.0.7.0

    When we call the token end-point, if we don't pass any cookies, all is good, we receive the tokens.

    On the other hand, if I do the exact same call but with cookies, we get a "400 Bad Request" and an error message stating: "The authenticated client id: [TEST@UAT.CA] does not match the client id in the request body". But in the request it's the OAuth Client Id (client_id=lY07BblWZqhgyurj3bht) whereas in the cookies there are sessions cookies for the user that logged in (TEST@UAT.CA).

    Would it be possible to have the token end-point ignore the cookies since it's the authorization_code that is to be considered?

    In a nutshell (complete cURL calls below):

    curl -v -k "https://uat-abcdef-sso.iad.ca.inet/isam/sps/oauth/oauth20/token" -b $CURL_COOKIEJAR_FILE_1 -c $CURL_COOKIEJAR_FILE_1 -d "code=$OAUTH_AUTHZCODE&code_verifier=$OAUTH_PCKE_CODEVERIFIER_1&redirect_uri=$OAUTH_REDIRECTURI&client_id=lY07BblWZqhgyurj3bht&grant_type=authorization_code"

    gives:
    {
    "error_description":"FBTOAU220E The authenticated client id: [TEST@UAT.CA] does not match the client id in the request body.",
    "error":"invalid_client"
    }

    and

    curl -v -k "https://uat-abcdef-sso.iad.ca.inet/isam/sps/oauth/oauth20/token" -c $CURL_COOKIEJAR_FILE_1 -d "code=$OAUTH_AUTHZCODE&code_verifier=$OAUTH_PCKE_CODEVERIFIER_1&redirect_uri=$OAUTH_REDIRECTURI&client_id=lY07BblWZqhgyurj3bht&grant_type=authorization_code"

    gives:
    {
    "access_token":"Cukz9HQL9BNixnVxkvRw",
    "refresh_token":"o2a9UNW1nbodkOqDQQrqaILOczOAWsYe7fxHVXeV9aFiKJiAXBtJEnQmPbhnQWq9DHVWJGJ3ZVNl87vKgOxcP0xzCbvC1kI58FypwaunCNj4JvyCpoaDqRuM9uBaRcwWwYGBX5VD92OygslG6BeyoXfq6O61We5UYCgojCwIA749AR5GAvFY1dDJTY2v5rOr1ogryxhrGHgZXwM98BhRWYrmHUyjrNHurIZy8bvtVQW3clUXWNHYDpZTnDvBrB1hJomAlel9wvx8NNCIkOpgxl6T5PakaTublmpwaU8YFZWu65zKi80TMzUvz21y8PUDkeFXtEhQGCk4KZYXfxxVhjlzBCCgcvb6SIalCXmqot5i7sNxSPWmczTQNeJ0EPnbWSBlV8EO5WarVfvI2f9x1eqas7cvtoVCLVaLV7wg1ruK0EOGVaVrBmorjGvNJuyeZmN3alvK8XYJXILlSKuGbpGcEu2nFoxT75j3ZWlRKzEyNEK9vmiP",
    "token_type":"bearer",
    "expires_in":1499
    }

    --Complete cURL calls--

    with cookies:
    [lbeaudry@managementnode:~] $
    [lbeaudry@managementnode:~] $ curl -v -k "https://uat-abcdef-sso.iad.ca.inet/isam/sps/oauth/oauth20/token" -b $CURL_COOKIEJAR_FILE_1 -c $CURL_COOKIEJAR_FILE_1 -d "code=$OAUTH_AUTHZCODE&code_verifier=$OAUTH_PCKE_CODEVERIFIER_1&redirect_uri=$OAUTH_REDIRECTURI&client_id=lY07BblWZqhgyurj3bht&grant_type=authorization_code"
    * About to connect() to uat-abcdef-sso.iad.ca.inet port 443 (#0)
    * Trying 1.2.3.4...
    * Connected to uat-abcdef-sso.iad.ca.inet (1.2.3.4) port 443 (#0)
    * Initializing NSS with certpath: sql:/etc/pki/nssdb
    * skipping SSL peer certificate verification
    * SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    * Server certificate:
    * subject: CN=*.iad.ca.inet,OU=SECURITY-OPS,O=abcdef Corporation,L=Saint-Elsewhere,ST=QC,C=CA
    * start date: Feb 21 17:55:37 2019 GMT
    * expire date: May 11 17:55:37 2021 GMT
    * common name: *.iad.ca.inet
    * issuer: CN=abcdefIssuingCA-Private-1,DC=iad,DC=ca,DC=inet
    > POST /isam/sps/oauth/oauth20/token HTTP/1.1
    > User-Agent: curl/7.29.0
    > Host: uat-abcdef-sso.iad.ca.inet
    > Accept: */*
    > Cookie: PD-ID=JBILSWuZXv5DYJTHWwqQPHYK2hkEQsmd4y/j4E+wpgLLHtywRAyXq31JLQ/LZVNzT48Mn2CppLp7TDAZ0RByjdw8J0frFAOiXSh1yBkrYYj2J4hF9b4X9uWBswgeMElkfKcBYNWl4S7AOQ8gQNg2OKz6n5sPIKcELBIEHCctZmZOSdDHRjPyg7j+F0SxN1Tb1orZYkLw0P6ByN5raRWJX9lKC9s1UL/IfUi2hfItDnZ/dBdWN00mY6QnULQi8BmEUVVIdbAGphwe7F+qTSEhD97OECLcpVGHiim36M2QO5BDA93OLCBOtHxaRVVDCxCvEXfvioPiWpWaBmvJcLjoTBTP7rREJySEr/uZDlp3qpvF2lJ/l6fMNCzEGSARnOVVD1Y1Nmcg92lxs/6jJaE8e7/FHdTBb6fl/+6QReASAIh3exN0KL9fvoJATgMtUJy1V+A0cGB2Q8hom/49djPu8NDJIbLFP9wYv9M3CR7RwQs=; PD-S-SESSION-ID=1_2_1_C8E0ZBieszIJFbvrK-67DZDRz7oGjyfMf0q1FjLPAXS2bBHV; AMWEBJCT!%2Fisam!JSESSIONID=0000vXZu0v_azVZKUJkNLC8p_mH:4ecf52cc-79fb-482a-8227-5d6e51124eb0
    > Content-Length: 207
    > Content-Type: application/x-www-form-urlencoded
    >
    * upload completely sent off: 207 out of 207 bytes
    < HTTP/1.1 400 Bad Request
    < content-language: en-US
    < content-type: application/json;charset=UTF-8
    < date: Thu, 12 Nov 2020 19:19:29 GMT
    < p3p: CP="NON CUR OTPi OUR NOR UNI"
    < transfer-encoding: chunked
    < x-frame-options: SAMEORIGIN
    < cache-control: no-store
    < isam-session-timeouts: 1800
    < content-security-policy: frame-ancestors 'self'
    < strict-transport-security: max-age=31536000; includeSubDomains
    < pragma: no-cache
    < Strict-Transport-Security: max-age=31536000; includeSubDomains
    < cache-control: no-cache, no-store, must-revalidate,private
    < X-Frame-Options: SAMEORIGIN
    <
    * Connection #0 to host uat-abcdef-sso.iad.ca.inet left abcdef
    {"error_description":"FBTOAU220E The authenticated client id: [TEST@UAT.CA] does not match the client id in the request body.","error":"invalid_client"}[lbeaudry@managementnode:~] $
    [lbeaudry@managementnode:~] $
    [lbeaudry@managementnode:~] $

    without cookies:
    [lbeaudry@managementnode:~] $
    [lbeaudry@managementnode:~] $ curl -v -k "https://uat-abcdef-sso.iad.ca.inet/isam/sps/oauth/oauth20/token" -c $CURL_COOKIEJAR_FILE_1 -d "code=$OAUTH_AUTHZCODE&code_verifier=$OAUTH_PCKE_CODEVERIFIER_1&redirect_uri=$OAUTH_REDIRECTURI&client_id=lY07BblWZqhgyurj3bht&grant_type=authorization_code"
    * About to connect() to uat-abcdef-sso.iad.ca.inet port 443 (#0)
    * Trying 1.2.3.4...
    * Connected to uat-abcdef-sso.iad.ca.inet (1.2.3.4) port 443 (#0)
    * Initializing NSS with certpath: sql:/etc/pki/nssdb
    * skipping SSL peer certificate verification
    * SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    * Server certificate:
    * subject: CN=*.iad.ca.inet,OU=SECURITY-OPS,O=abcdef Corporation,L=Saint-Elsewhere,ST=QC,C=CA
    * start date: Feb 21 17:55:37 2019 GMT
    * expire date: May 11 17:55:37 2021 GMT
    * common name: *.iad.ca.inet
    * issuer: CN=abcdefIssuingCA-Private-1,DC=iad,DC=ca,DC=inet
    > POST /isam/sps/oauth/oauth20/token HTTP/1.1
    > User-Agent: curl/7.29.0
    > Host: uat-abcdef-sso.iad.ca.inet
    > Accept: */*
    > Content-Length: 207
    > Content-Type: application/x-www-form-urlencoded
    >
    * upload completely sent off: 207 out of 207 bytes
    < HTTP/1.1 200 OK
    < content-language: en-US
    < content-type: application/json;charset=UTF-8
    < date: Thu, 12 Nov 2020 19:19:48 GMT
    < p3p: CP="NON CUR OTPi OUR NOR UNI"
    < transfer-encoding: chunked
    < x-frame-options: SAMEORIGIN
    < cache-control: no-store, no-cache=set-cookie
    < isam-session-timeouts: 0
    < expires: Thu, 01 Dec 1994 16:00:00 GMT
    < content-security-policy: frame-ancestors 'self'
    < strict-transport-security: max-age=31536000; includeSubDomains
    < pragma: no-cache
    < Strict-Transport-Security: max-age=31536000; includeSubDomains
    < cache-control: no-cache, no-store, must-revalidate,private
    < X-Frame-Options: SAMEORIGIN
    * Added cookie AMWEBJCT!%2Fisam!JSESSIONID="0000d-3Zj1JD5r7ZSW-DNPG_H2e:4ecf52cc-79fb-482a-8227-5d6e51124eb0" for domain uat-abcdef-sso.iad.ca.inet, path /, expire 0
    < Set-Cookie: AMWEBJCT!%2Fisam!JSESSIONID=0000d-3Zj1JD5r7ZSW-DNPG_H2e:4ecf52cc-79fb-482a-8227-5d6e51124eb0; Path=/; Secure; HttpOnly
    <
    {"access_token":"Cukz9HQL9BNixnVxkvRw","refresh_token":"o2a9UNW1nbodkOqDQQrqaILOczOAWsYe7fxHVXeV9aFiKJiAXBtJEnQmPbhnQWq9DHVWJGJ3ZVNl87vKgOxcP0xzCbvC1kI58FypwaunCNj4JvyCpoaDqRuM9uBaRcwWwYGBX5VD92OygslG6BeyoXfq6O61We5UYCgojCwIA749AR5GAvFY1dDJTY2v5rOr1ogryxhrGHgZXwM98BhRWYrmHUyjrNHurIZy8bvtVQW3clUXWNHYDpZTnDvBrB1hJomAlel9wvx8NNCIkOpgxl6T5PakaTublmpwaU8YFZWu65zKi80TMzUvz21y8PUDkeFXtEhQGCk4KZYXfxxVhjlzBCCgcvb6SIalCXmqot5i7sNxSPWmczTQNeJ0EPnbWSBlV8EO5WarVfvI2f9x1eqas7cvtoVCLVaLV7wg1ruK0EOGVaVrBmorjGvNJuyeZmN3alvK8XYJXILlSKuGbpGcEu2nFoxT75j3ZWlRKzEyNEK9vmiP","token_type":"bearer","expires_in":1499}[lbeaudry@managementnode:~] $
    [lbeaudry@managementnode:~] $
    [lbeaudry@managementnode:~] $

    ------------------------------
    Louis Beaudry
    Access Management
    Intact Financial Corporation
    ------------------------------


  • 2.  RE: OAuth Authorization code flow -- token endpoint problem

    Posted Sun November 15, 2020 01:41 PM
    Hi Louis,

    I encountered the same problem and my solution was to configure a second junction which doesn't pass any user credentials to sps. That way any cookies the user already has won't interfere with the token endpoint.

    ------------------------------
    Laurent LA Asselborn
    ------------------------------



  • 3.  RE: OAuth Authorization code flow -- token endpoint problem

    Posted Mon November 16, 2020 01:50 AM
    Edited by Shane Weeden Mon November 16, 2020 01:57 AM
    Why would you have a scenario where an OAuth client connects to the token endpoint using cookies in the first place?  Typically the authorization code flow is executed by the BACKEND portion of a web application rather than client-side. Even if you are using public clients and client-side flows to the token endpoint, which also requires CORS if not served by the same site as the authorization server, such requests could be using fetch APIs with credentials: "omit" which should remove browser cookies. If you think this doesn't apply, what am I missing?

    ------------------------------
    Shane Weeden
    IBM
    ------------------------------



  • 4.  RE: OAuth Authorization code flow -- token endpoint problem

    Posted Mon November 16, 2020 02:28 AM
    Hi Shane,

    You are correct that usually the token endpoint is called by clients who don't have an existing session. In my specific case I encountered the problem while writing a simple html page to test the OAuth flow. The first version of the page used simple HTML forms to post the data, which automatically included the session cookie because the page was hosted on the same WebSEAL. Later versions of the page used indeed XHR calls.

    ------------------------------
    Laurent LA Asselborn
    ------------------------------