Automating Authorization Code Flow

I’m following the Authorization Code Flow API here, but running into an issue with automation the login. This works fine and well to get the browser open and have the user manually authenticate through the Okta sign in page, however this app also needs to be scriptable (i.e. no user to manually login through browser).

I see for regular authentication you can supply the username and password and successfully login by hitting the endpoint. Can someone point me to an example or API doc that shows how to do this for the authorization code flow?

Hi @vperiyasamy

You can authenticate the user via API using /api/v1/authn endpoint (doc here) and retrieve a sessionToken. From there, you can pass the sessionToken as query parameter on the authorization endpoint and Okta will create the session automatically and redirect the user to the callback endpoint (doc here).

Hi @dragos,

Thanks for the response. I tried your suggestion and was able to successfully log in using the session token. However, the callback URL comes back as follows:


so it does not seem to register the fact that I had logged in prior to the callback being called. Normally the authorization code should be a query parameter in this URL right?

To add to this, if I directly paste the URL with the session token into my browser it correctly goes to the callback with the code as a query parameter. Is it possible to cut the browser out of this process or is it necessary for some reason?

Yes, the authorization code should be returned as query parameter.

Here is a cURL request on the authorization endpoint with the sessionToken, using verbose and follow location. The authorization code was sent successfully and received by the application.

[root@vps ~]# curl -Lv ""
* About to connect() to port 443 (#0)
*   Trying
* Connected to ( port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate:
*       subject: CN=*,O="Okta, Inc.",L=San Francisco,ST=California,C=US
*       start date: May 28 00:00:00 2019 GMT
*       expire date: May 28 12:00:00 2021 GMT
*       common name: *
*       issuer: CN=DigiCert SHA2 High Assurance Server CA,,O=DigiCert Inc,C=US
> GET /oauth2/aus38el88lfcL6PFg2p7/v1/authorize?response_type=code&client_id=0oa2fatx70JGiU2TA2p7& HTTP/1.1
> User-Agent: curl/7.29.0
> Host:
> Accept: */*
< HTTP/1.1 302 Found
< Date: Thu, 31 Oct 2019 23:58:37 GMT
< Server: nginx
< Public-Key-Pins-Report-Only: pin-sha256="r5EfzZxQVvQpKo3AgYRaT7X2bDO/kj3ACwmxfdT2zt8="; pin-sha256="MaqlcUgk2mvY/RFSGeSwBRkI+rZ6/dxe/DuQfBT/vnQ="; pin-sha256="72G5IEvDEWn+EThf3qjR7/bQSWaS2ZSLqolhnO6iyJI="; pin-sha256="rrV6CLCCvqnk89gWibYT0JO6fNQ8cCit7GGoiVTjCOg="; max-age=60; report-uri=""
< Content-Length: 0
< X-Okta-Request-Id: Xbt1LO6D76S734kQkdT3QgAAAFs
< X-XSS-Protection: 1; mode=block; report=
< P3P: CP="HONK"
< X-Rate-Limit-Limit: 2000
< X-Rate-Limit-Remaining: 1994
< X-Rate-Limit-Reset: 1572566327
< Content-Security-Policy-Report-Only: default-src 'self'; connect-src 'self' * *; script-src 'unsafe-inline' 'unsafe-eval' 'self'; style-src 'unsafe-inline' 'self'; frame-src 'self'; img-src 'self' * data:; font-src data: 'self'; report-uri; report-to csp-report
< Report-To: {"group":"csp-report","max_age":31536000,"endpoints":[{"url":""}],"include_subdomains":true}
< Referrer-Policy: no-referrer
< Cache-Control: no-cache, no-store
< Pragma: no-cache
< Expires: 0
< Location:
< Content-Language: en
< Strict-Transport-Security: max-age=315360000
< X-Robots-Tag: none
< Set-Cookie: JSESSIONID=31FABFFE0EF4CC2042B384373A68A6FA; Path=/; Secure; HttpOnly
< Set-Cookie: t=sea; Path=/
< Set-Cookie: DT=DI0tVZyqq63S7uv1zBNlks4Nw; Expires=Sat, 30-Oct-2021 23:58:37 GMT; Path=/; Secure
< Set-Cookie: sid=102WqvnROu6RaGQVdS1ZRfkVw; Path=/; Secure
< Set-Cookie: proximity_0b24e00d88cec09bf8cfff53883619bf=b/tZN6DHRBgZscvDZP52Z9xJWo2Jf2yTDy5/QHTorcyKdqTOhXJG1ALK3JpsoJt+DfDMbnS+RSpy+q7r2O6xA8ysiwLZqqszVi3rbuwyykDxWMIv9LC92lvvKi2I5l6Dd/Y12qWUegQG8PoH2mPVH3tCP7TUuS2GExw09ejR5V/mKuIa0VKSRqf8/OyqQEFJ; Expires=Fri, 30-Oct-2020 23:58:37 GMT; Path=/; Secure
* Connection #0 to host left intact
* Issue another request to this URL: ''
* About to connect() to port 443 (#1)
*   Trying
* Connected to ( port 443 (#1)
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate:
*       subject: CN=*
*       start date: Mar 11 00:00:00 2019 GMT
*       expire date: Mar 11 12:00:00 2020 GMT
*       common name: *
*       issuer: CN=RapidSSL RSA CA 2018,,O=DigiCert Inc,C=US
> GET /samples/okta-tokens/prod-custom-as.php?code=h2TcdBwaD-mb6ievje7x&state=abc HTTP/1.1
> User-Agent: curl/7.29.0
> Host:
> Accept: */*
< HTTP/1.1 200 OK
< Date: Thu, 31 Oct 2019 23:58:37 GMT
< Server: Apache/2.4.35 (Win64) PHP/7.0.32
< X-Powered-By: PHP/7.0.32
< Content-Length: 5250
< Content-Type: text/html; charset=UTF-8
        my content here
* Connection #1 to host left intact
1 Like

Hi @dragos, thanks for the help so far. I’ve been trying to debug this but to no avail. I am able to correctly obtain a sessionToken and verify it through the sessions API. I can also still call the authorize? endpoint by browser and obtain the authorization code through callback.

However, when I make a non-browser request (through cURL or Postman) and use the prompt=none flag, the callback says “login required” as mentioned above. If I don’t include the prompt flag but still include the sessionToken, it navigates to the login page. Are there any other possible reasons it might not be using the sessionToken properly without a browser?

Here are the full list of query params I am supplying to the authorize? endpoint:


After looking into this further, the browser authorization does not work in incognito mode, leading me to believe that there are some active cookies from logging in previously through browser which are authenticating me (and not my sessionToken). However, the API says that only a sessionToken. Could you shed some light on which cookies are important and whether I can include this is in my request to the authorize? endpoint?

Hi @vperiyasamy

The “sid” cookie is important in authenticating the user. Please feel free to open a support ticket with us at in order to further discuss this integration.