One of my apps requires the authorization code flow to be initiated via POST request when signing a nonce. I notice that when POST is used, Okta will return a HTTP 404, whereas a GET will succeed.
Along with this the documentation at OpenID Connect & OAuth 2.0 API | Okta Developer only mentions GET.
Can anyone confirm?
Yep that’s correct, it has to be a redirect.
Note: When making requests to the
/authorizeendpoint, the browser (user agent) should be redirected to the endpoint. You can’t use AJAX with this endpoint.
We have a PSD2 compliant banking application that would require HTTP POST for the authorization code flow, as we need to pass a JWT token to be signed in the nonce field.
Are there any customization options which could be used to work around this POST limitation?
I’ve been reading the Scopes and supported endpoints documentation (/docs/guides/implement-oauth-for-okta/scopes/) and I see POST is supported when updating a resource:
Are there any additional options available which could help me achieve this when using a custom authorization server(/docs/guides/customize-authz-server/overview/), similar to the default one in Okta Developer edition?
Here’s a successful login to the app via HTTP GET:
Here’s the HTTP POST that is affected:
POST https://dev-67216185.okta.com/oauth2/v1/authorize HTTP/1.1
sec-ch-ua: “Chromium”;v=“92”, " Not A;Brand";v=“99”, “Google Chrome”;v=“92”
sec-ch-ua-mobile: ?0
Upgrade-Insecure-Requests: 1
DNT: 1
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36
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.9
Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: navigate
Sec-Fetch-Dest: document
Postman-Token: 82b1876a-e517-4232-8608-b9d132461d64
Host: dev-67216185.okta.com
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Length: 1390
Cookie:
client_id=0oa1bcgx4fr2RPJLp5d7&nonce=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJsZWdhbF9lbnRpdHlfaWQiOiJiYW5rMiIsImNvbXBhbnlfaWQiOiJTRUNPTkQiLCJ1c2VyX2lkIjoiNTc3YjNmNzItNjY0Yi00MDcxLWJmM2QtNjQ3NTgzMjdmNWFhIiwibG9naW5faGludCI6IjAwdTE4MWZ4aTd5NzFKdER5NWQ3IiwidHhfYW1vdW50IjoiRVVSIDUwMC4wMCIsInR4X3ByaWNlX3RvbGVyYW5jZSI6IkVVUiA1MC4wMCIsInR4X2NvdW50ZXJwYXJ0eSI6IkR1bW15IENQIENvLiIsInR4X2liYW4iOiJEVU1NWSIsInR4X3JlZmVyZW5jZSI6IjdlMDllMGJlNjExNTQyYzViYmZkMDBmZDcxNTMyOTYxIiwidHhfc3VtbWFyeSI6IlBPI0RVTU1ZIGNyZWF0ZWQgb24gQXVnIDI1dGggd2l0aCBEdW1teSBDUCBDby4gZm9yIEVVUiA1MDAuMDAiLCJ1c2VyX2lwIjoiMTAuMTk0LjE1Ni40Iiwid2V0cmFkZV91c2VyX2lkIjoiNTc3YjNmNzItNjY0Yi00MDcxLWJmM2QtNjQ3NTgzMjdmNWFhIiwidHhfYWNjb3VudF9zZWxsZXIiOiJEVU1NWSIsInR4X2FjY291bnRfYnV5ZXIiOiJEVU1NWSIsInR4X3RyYWRlX2lkIjoiYjRiNDBlYmUtY2M2OC00M2EyLTkzNjctNjM3Y2MzMTI3YmVkIiwiaWF0IjoxNjI5OTAzMzkzfQ.3f1Tas3MQYdAaMYj-SU0Tj5-NWiyNz5c044J7YPB4iw-uJw763uE8a07xyvbhhl1XrQzIq8MsId5fmXXvgDOVXw4jkB71Ngoxq2-N9Z66HqCP9SoBgn6qNtQ5K8kUDULEE6Q08eE_iqIua6qxqc2obThDZ8Li6OCvGewmlNtwSnP11t__N-WjY3Sff299lltKTBFMZMACz5DtwS4KyKyiQriXlSQdAtwDcLS0O62wa6jTm3VK14XAgdla4SoJS2pwSzwITC4_Ry-5TkwUVsSMFpWa2N_BPRL3_WnEAnId4VP9xkBeG_lYv8ZHdG5bwiakkZ-IV6yTJwtcPwpxtmWUQ&redirect_uri=https%3A%2F%2Ftest-bank2-ops1.preview-wetrade.com%3A443%2Fapi%2FsignableTransactions%2Fsign&response_type=code&scope=openid%20profile&state=7e09e0be611542c5bbfd00fd71532961&ui_locales=en-US
The error returned is simply a HTTP 404.
The doc you referenced ("/docs/guides/implement-oauth-for-okta/scopes/") is specifically for the Okta API endpoints (Users, Groups, etc). You would still make a GET request to /authorize so I’m not sure what you meant.
Is there a reason why you need to pass a JWT in the nonce parameter?
I did find this doc which might be helpful:
Heres an example of a decoded JWT token which we have sitting in the nonce field:
{
"alg": "HS512"
} (header)
{
"iss": " https://example.bank.com/WeTrade/",
"nonce": "nonce",
"aud": ”xxx",
"exp": 1532606980,
"iat": 1532599780,
"tx_amount": " 500.00",
"tx_price_tolerance": " 50.00",
"tx_counterparty": "Dummy CP Co.",
"tx_iban": "Not yet available",
"tx_reference": "500bdffcc8ea4e52a81310acd8071411",
"tx_summary": "PO#DUMMY created on May 6th with Dummy CP Co. for 500.00",
"sub": ”xxx",
"companyId": ”xxx",
"bankLegalEntityId": " XXXXXXXXXXX ",
"auth_user_id": ”xxx",
"userId": ”xxx",
"user_ip": "10.85.xx.xx",
"c_hash": "_xxx",
"nbf": xxx,
"auth_time": 1532599779
} (payload)
{
…
} (signature
It includes the standard OIDC claims plus some additional fields for bank transaction data. (dummy info of course for this example.)
we can move this JWT from the nonce field to a “custom” field if needed, but as you can guess, this isn’t something we can pass easily using a GET due to the payload size, so a POST is used instead.
I’m aware of the link about PSD2, but that doesn’t really help me, that’s just talking conceptually.
For us to consider adding our application to the okta directory at some point in the future, we would need to figure this part out.
Are there any features in the okta identity engine that would workaround this requirement?
(Does it support POST for auth code flow?)
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.