How can I exchange a sessionToken for an AccessToken in the backend for an application/client with PKCE

Application/Client Grant Type: Authorization_Code with PKCE

I am building an Integration Test Suite, where I need to obtain the access_token using only api calls(backend).
I am able to use the Proprietary OKTA Authentication API and subsequently the MFA verify api{{factorId}}/verify to obtain the sessionToken.

Next I am trying to exchange the sessionToken for AccessToken as per the doc
I am getting the response: Error: connect ECONNREFUSED (this is the callback url)

I am expecting an IDToken and AccessToken in the response.

Any help is appreciated.

What is the URL you are redirected to, it should include id_token requested as a part of URL

the redirect URL has the error Response:

I believe as the grant_type configured is authorization_code , I have to use response_type=code…
And when I do that, then I get the following redirect URL:

Check this one

try to provide prompt=none param while sending the initial request to /authorize

I tried that as well… here is what I get inspite of a valid sessionToken following successful authentication seconds ago…


are you sure the sign-on policy for this application doesn’t require re-authentication?

@phi1ipp yes you are correct it was configured Every Sign On,
I changed it to Once per Session. …still getting the same issue…does it take time to change…Thanks much…

I suggest you to remove the application sign-on policy and keep it as default one, which just allows access to the application. Test if it works this way.

You can always introduce MFA for the initial sign-on which you handle with auth-js

1 Like

@phi1ipp. thanks I removed the application sign-on policy falling back to the default policy. Now I get the code in the redirect location header.

Thanks Much.

Since My OKTA Org policy is configured for MFA enforced once per session. I am getting prompted for the MFA when I hit the {{url}}/api/v1/authn but I am able to call the TOTP verify endpoint to get passed the MFA and obtain the SessionToken prior to making the /authorize call.
In conclusion, Removing the custom sign-on policy for the application did the trick.
Mucho Gracias @phi1ipp