Mapy.cz
Nástroje pro vývojáře
Bug: POST /token nepřijímá http basic auth
David Obdržálek
20.5.2024 v 0:06
dle specifikace OAuth 2.0 by metoda POST /token měla přijímat data v typu application/x-www-form-urlencoded (RFC 6749, sekce 4.1.2.)
Zde v dokumentaci máte uvedený JSON, s tím to také funguje. Není to ale v souladu se standardem a rozchodit to s knihovnou next-auth, vůbec najít, v čem byla chyba, dalo dost práce :)
Možná by to mohlo umět přijímat oba formáty.
Děkuji,
David O
Ondřej Žára • Webmaster Guru
20.5.2024 v 13:43
mohu se optat, co přesně se stane, pokud data pošlete v application/x-www-form-urlencoded? Na první pohled mi přijde, že by to mělo fungovat -- a pokud nefunguje, pokusím se zařídit, aby fungovalo. Potřebuji k tomu však vědět, kdy přesně se pokoušíte, jak vypadá tělo/hlavičky požadavků a z jaké IP adresy tak činíte.
David Obdržálek reagoval na příspěvek od Ondřej Žára
21.5.2024 v 22:31
omlouvám se, moje chyba, problém nebyl v content-type, ale v těle požadavku.
Stejně ale dost práce to s pomocí next-auth (5.0.0-beta.18) / oauth4webapi (2.10.4) rozchodit.
1. pokus neposílal client_id a client_secret v těle požadavku, ale http auth v hlavičce
POST https://login.szn.cz/api/v1/oauth/token
Accept: application/json
Authorization: Basic ZTQzMzY0ZmYz....
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
User-Agent: oauth4webapi/v2.10.4
redirect_uri=http%3A%2F%2Flocalhost%3A3000%2Fapi%2Fauth%2Fcallback%2Fseznam&code_verifier=uHUSlWlHaWHsJ_AC6xMwjuIFADi4vq3tUuuhHV3gDIM&code=2%7CjIznFzf8xPUbN1BSVwBHUFVRRQ5BWhNSNzATEGA9Zn0Sib9K5XZeKl8o3A_zaX0lSqDVkJinXp7AYZ26yjOUC3Q&grant_type=authorization_code
Odpověď: 400 BAD REQUEST
error { error: 'invalid_grant', message: 'client_id mismatch' }
2. pokus, přesvědčil jsem oauth4webapi, že bude posílat client_id a client_secret v těle požadavku (token_endpoint_auth_method: 'client_secret_post')
POST https://login.szn.cz/api/v1/oauth/token
Accept: application/json
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
User-Agent: oauth4webapi/v2.10.4
redirect_uri=http%3A%2F%2Flocalhost%3A3000%2Fapi%2Fauth%2Fcallback%2Fseznam&code_verifier=2i1gAkMk_tEE3954bEupAfxuKP4Lvm4zksV_M1A-_78&code=2%7CjIznFzfKyvUbN1BSVwBHUFVRRQ5BWhNSNyICA1UcZn0SbPQlwuhuGhwnKA2s-StuZMifJ8-2RLi9uxqlWEoUAV8&grant_type=authorization_code&client_id=e43364ff312f884661189efd84d3716b83206d7cac0f7ddb&client_secret=...
Odpověď: 400 BAD REQUEST
error { error: 'invalid_grant' }
3. pokus, přesvědčil jsem next-auth, že nebude používat PKCE, ale obyčejný state verifier
POST https://login.szn.cz/api/v1/oauth/token
Accept: application/json
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
User-Agent: oauth4webapi/v2.10.4
redirect_uri=http%3A%2F%2Flocalhost%3A3000%2Fapi%2Fauth%2Fcallback%2Fseznam&code_verifier=auth&code=2%7CjIznFzfCy_UbN1BSVwBHUFVRRQ5BWhNSNx8OKVkoZn0S-D0VlrkcYPqpKSgfsVTrwGT_n9qds5YWQCKHRkt6ig8&grant_type=authorization_code&client_id=e43364ff312f884661189efd84d3716b83206d7cac0f7ddb&client_secret=...
Odpověď: 200 OK 🎉
Takto už mi to funguje bez zásahů do knihoven :-)
Stejně by nebylo špatné, kdyby Vaše strana uměla přijímat client_id a client_secret jako http basic auth. I ten PKCE verifier (https://datatracker.ietf.org/doc/html/rfc7636) by se hodil.
Děkuji a zdravím,
David O
Ondřej Žára • Webmaster Guru
22.5.2024 v 8:10
jsem rad, ze vam to uz funguje.
Co se tyce podpory Authorization hlavicky, tam to moc dobre nevidim - je to vlastne uz treti mechanismus prijmu techto dat (vedle JSONu a x-www-form-urlencoded) a nejsem si jisty, jak velky uzitek to prinasi.
PKCE ve skutecnosti podporujeme, ale narazil jste na chybu nasi implementace. Zjistil jsem, ze code_challenge ukladame v okamziku, kdy se uzivatel prihlasi (zada jmeno a heslo). Pokud k nam na overeni posilate jiz prihlaseneho uzivatele, tak nedojde k ulozeni code_challenge a tim padem ani k naslednemu overeni code_verifier. Asi to muzete experimentalne overit tim, ze zapnete PKCE a pokusite se o prihlaseni v anonymnim okne prohlizece.
Zkusim to vyhledove nejak napravit a vyresit.
S pozdravem
Ondrej Zara
Ondřej Žára • Webmaster Guru
22.5.2024 v 14:05
David Obdržálek reagoval na příspěvek od Ondřej Žára
22.5.2024 v 17:07
děkuji, že se tomu věnujete :-)
PKCE mi bohužel nefunguje ani u přihlášeného uživatele, ani u nepřihlášeného uživatele v anonymním okně.
Code Challange Method je S256 (SHA256). Knihovna, kterou používám, code challenge v plaintextu neumí.
GET https://login.szn.cz/api/v1/oauth/auth?scope=identity%2Ccontact-phone%2Cavatar&response_type=code&client_id=e43364ff312f884661189efd84d3716b83206d7cac0f7ddb&redirect_uri=http%3A%2F%2Flocalhost%3A3000%2Fapi%2Fauth%2Fcallback%2Fseznam&code_challenge=22heX1LKL-OJyVhBwXaojWm_FOVdyiTThkjqPxZpegY&code_challenge_method=S256
...
POST https://login.szn.cz/api/v1/oauth/token
Accept: application/json
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
User-Agent: oauth4webapi/v2.10.4
redirect_uri=http%3A%2F%2Flocalhost%3A3000%2Fapi%2Fauth%2Fcallback%2Fseznam&code_verifier=VyVtetPZUei4rN_nXbyzMP26Cx-X2-QolXgqTXHDJ0o&code=2%7CjIznFzeftf4bN1BSVwBHUFVRRQ5BWhNSNwwYGXUOZn0SQ2QljliMtivjMCeQt0dpw-7C5_LANglnA8TgpgGWsGo&grant_type=authorization_code&client_id=e43364ff312f884661189efd84d3716b83206d7cac0f7ddb&client_secret=...
Odpověď: 400 BAD REQUEST
error { error: 'invalid_grant' }
HTTP Basic Auth asi není moc důležitý, hodil by se k tomu, že ho některé knihovny ho používají jako default. Třeba oauth4webapi, kterou používá knihovna next-auth. Tato metoda (client_secret_basic) je uvedená v dokumentaci OAuth (https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-endpoint-auth-method).
Je to v zásadě jednoduché, posílá se se base64(client_id + ":" + client_secret)
Kdyby byl client_id 123 a client secret 456, poslalo by se base64("123:456"), tedy
Authorization: Basic MTIzOjQ1Ng==
Děkuji,
David O
Ondřej Žára • Webmaster Guru reagoval na příspěvek od David Obdržálek
10.6.2024 v 13:04
omlouvam se za pozdni odpoved, nemel jsem ted bohuzel cas se PKCE venovat. Nyni jiz mam - ale za tak dlouho zpetne nemam potrebne logy. Pokud byste chtel, muzete se pokusit o autorizaci vcetne code_challenge (a nasledne code_verifier) a dat mi vedet, jaky den a v kolik hodin jste to zkousel. Projdu logy a podivam se.
Hned na prvni pohled:
>>> base64.urlsafe_b64encode(sha256("VyVtetPZUei4rN_nXbyzMP26Cx-X2-QolXgqTXHDJ0o".encode()).digest())
b'22heX1LKL-OJyVhBwXaojWm_FOVdyiTThkjqPxZpegY='
...a ve vasem pozadavku s code_challenge nevidim ten padding (rovnitko) na konci. Ale definitivneji to budu moct rozhodnout jen pohledem do logu.
Petra Kováčová
9.7.2024 v 22:10
Filip Skokan reagoval na příspěvek od Ondřej Žára
26.8.2024 v 23:42
zadne tam byt nema, RFC 7636 jasne definuje S256 code_challenge_method pouzivajic "Base64url Encoding" jako "with all trailing '=' characters omitted"
