Sso post err

Im using openresty
When I get the authorization code, I always get an error 404 when I send a post request to sso.

openresty log:
2022/03/18 04:13:25 [debug] 29706#0: *63 [lua] http.lua:638: send_request(): {“body”:“grant_type%3Dauthorization_code%26code%3Dmycode”,“path”:"/v2/oauth/toke",“headers”:{“Content-Length”:63,“Authorization”:“Basic somestring”,“User-Agent”:“lua-resty-http/0.12 (Lua) ngx_lua/10020”,“Host”:“”,“Content-Type”:“application/x-www-form-urlencoded”},“query”:"",“method”:“POST”}
2022/03/18 04:13:26 [debug] 29706#0: *63 [lua] callback.lua:61:

where is the error
Thanks for the kind help

Looks like you’re missing the n on your request URI. I.e. /v2/oauth/token not /v2/oauth/toke.

thank you for your seriousness
while i change th URI, it returned as 400 {“error”:“invalid_grant”,“error_description”:“Grant type is not supported.”}

thank you for your seriousness
while i change th URI, it returned as 400 {“error”:“invalid_grant”,“error_description”:“Grant type is not supported.”}

I was always stuck here 400 before

curl -XPOST -v -H “Content-Type:application/x-www-form-urlencoded” -H “Authorization:Basic url_safe_base64_string” -d ‘grant_type=authorization_code&code=X00WzkDmt0W86MpDVMWWgA’

return {“error”:“invalid_grant”,“error_description”:“Grant type authorization_code is not supported.”}

curl -XPOST -v -H “Content-Type:application/x-www-form-urlencoded” -H “Authorization:Basic url_safe_base64_string” -d ‘grant_type%3Dauthorization_code%26code%3DX00WzkDmt0W86MpDVMWWgA’

return {“error”:“invalid_grant”,“error_description”:“Grant type is not supported.”}

where is the diff? and why

Hmm, i was able to reproduce this. Give me a few to figure it out.

I think the gist of it is your authorization header isn’t right, but the error is less the clear…

To debug this, you should ensure that base64_encode("CLIENT_ID:CLIENT_SECRET") results in Q0xJRU5UX0lEOkNMSUVOVF9TRUNSRVQ=. Which might be as simple as removing the , true on ngx.encode_base64.

Thanks for your suggestion, I finally got the correct result .

OAuth 2.0 for Web Based Applications

Create a URL safe Base64 encoded string where the contents before encoding are your application’s client ID, followed by a :, followed by your application’s secret key (e.g. URL safe Base64(<client_id>:<secret_key>)).

not URL safe Base64(<client_id>:<secret_key>), the true just is Base64(<client_id>:<secret_key>)

I created a PR to make this clearer in the docs: Clarify Auth header requirements by Blacksmoke16 · Pull Request #68 · esi/esi-docs · GitHub.

In the end I don’t think it really matters if it was URL safe or not given, in my limiting testing, doesn’t ever include those chars anyway. The crux of the problem in your case was the lack of padding.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.