PKCE для OAuth: адна праверка закрывае крадзеж кода аўтарызацыі

Каб перахоплены код аўтарызацыі не ўдалося абмяняць на токены, для кожнай спробы OAuth Authorization Code стварайце новы code_verifier, перадавайце ў запыце толькі вытворны code_challenge з метадам S256 і патрабуйце verifier пры абмене кода. RFC 9700 патрабуе PKCE для публічных кліентаў, рэкамендуе яго канфідэнцыйным і называе S256 адзіным на сёння метадам, які не раскрывае verifier у запыце аўтарызацыі.

Поўны паток звязвае адказ з распачатай спробай праз state, выкарыстоўвае дакладны redirect URI і асобна абараняе ўжо выдадзеныя токены. Праверка PKCE спыняе абмен, калі ў таго, хто атрымаў код, няма адпаведнага verifier; яна не спыняе само перахопліванне кода і не замяняе абарону токена пасля выдачы.

Стварыце verifier і challenge для адной спробы

Перад перанакіраваннем карыстальніка кліент генеруе code_verifier крыптаграфічна бяспечным генератарам выпадковых значэнняў. Захоўвайце яго толькі ў кантэксце гэтай спробы да абмену кода. Калі карыстальнік пачаў некалькі ўваходаў паралельна, кожны павінен мець уласныя verifier і state, каб адказ не быў прывязаны да чужой спробы.

Спецыфікацыя PKCE задае для code_verifier даўжыню ад 43 да 128 дазволеных сімвалаў і рэкамендуе атрымаць яго з 32 выпадковых байтаў, закадаваных праз base64url. Псеўдаформула для challenge такая: code_challenge = BASE64URL(SHA256(ASCII(code_verifier))). Тут SHA256 прымяняецца да байтаў радка verifier, а вынік хэшавання кадзіруецца праз base64url без сімвалаў запаўнення.

У запыце аўтарызацыі яўна пазначайце code_challenge_method=S256. Калі параметр прапушчаны, метад па змаўчанні — plain: challenge тады супадае з verifier і раскрывае яго ў запыце, які праходзіць праз браўзер. Для патоку, разлічанага на абарону ад перахопу кода, не пераходзьце на plain пасля адмовы сервера прыняць S256.

Прайдзіце ўвесь абмен у правільным парадку

Ніжэй — умоўная схема параметраў, а не адрасы пэўнага пастаўшчыка. Пункты аўтарызацыі і выдачы токенаў, client_id і redirect_uri вызначаюцца канфігурацыяй зарэгістраванага кліента; выпадковыя значэнні ствараюцца нанова для кожнай спробы.

1. Кліент стварае code_verifier і непрадказальны state, захоўвае іх разам з абраным серверам аўтарызацыі і redirect URI ў кантэксце спробы карыстальніка. З verifier лакальна вылічаецца code_challenge.
2. Браўзер пераходзіць на пункт аўтарызацыі з response_type=code, client_id, redirect_uri, патрэбным scope, state, code_challenge і code_challenge_method=S256. Сам code_verifier у гэты URL не ўключаецца.
3. Пасля згоды карыстальніка сервер вяртае на redirect URI код і state. Кліент знаходзіць адпаведную спробу і параўноўвае атрыманы state з захаваным да таго, як прымаць код.
4. Кліент адпраўляе на пункт выдачы токенаў code, code_verifier і той жа redirect_uri, які ўказаў пры аўтарызацыі. Канфідэнцыйны кліент таксама праходзіць прадугледжаную для яго аўтэнтыфікацыю.
5. Сервер вылічае challenge з атрыманага verifier і параўноўвае яго са значэннем, прывязаным да кода. Толькі пасля паспяховай праверкі кода і астатніх умоў абмену ён можа выдаць токены.

Калі вэб-праграма абменьвае код на ўласным серверы, verifier захоўваецца на гэтым серверы ў прывязцы да спробы ўваходу. У настольнай праграме verifier застаецца ў кліенце да завяршэння абмену. Убудаваны ў публічную праграму client secret не замяняе PKCE, бо ўладальнік прылады можа атрымаць гэты агульны сакрэт з праграмы.

Звяжыце адказ з сесіяй і правільным адрасам

Рэкамендацыі Google для OAuth прапануюць параўноўваць атрыманы state з адпраўленым перад апрацоўкай адказу, а для настольных праграм настойліва раяць PKCE. Стварайце state непрадказальным і прывязвайце да сесіі, якая пачала аўтарызацыю. Пры адсутнасці або несупадзенні state спыняйце спробу; пасля паспяховага абмену выдаляйце часовыя state і verifier.

State і PKCE вырашаюць розныя задачы ў гэтай схеме: state дапамагае адхіліць адказ, не звязаны з запытам карыстальніка, а verifier перашкаджае абмяняць перахоплены код. RFC 9700 дапускае абарону ад падробленых запытаў да redirect endpoint праз PKCE без state, калі кліент пераканаўся, што сервер падтрымлівае PKCE. Асобная праверка state застаецца зразумелым выбарам для паказанага патоку.

Сервер аўтарызацыі павінен дакладна параўноўваць redirect URI з зарэгістраваным адрасам; для localhost-перанакіравання настольнай праграмы выключэнне датычыцца нумара порта. Пры абмене кода сервер звярае перададзены redirect_uri з тым, што выкарыстоўваўся пры выдачы гэтага кода. Ні кліент, ні сервер не павінны перанакіроўваць браўзер на адвольны адрас з параметра запыту: адкрыты перанакіравальнік дае шлях для ўцечкі кода.

Калі кліент працуе з некалькімі серверамі аўтарызацыі, ён захоўвае абранага выдаўца для кожнай спробы і правярае, адкуль прыйшоў адказ. Для гэтага можна параўноўваць issuer у адказе з захаваным значэннем; асобныя redirect URI для розных сервераў — іншы варыянт. Інакш кліент рызыкуе адправіць код на пункт выдачы токенаў не таго сервера.

Прымусьце сервер адхіляць няправільны код

Сервер прывязвае code_challenge і абраны метад да выдадзенага кода. Калі код быў выдадзены з challenge, запыт без verifier або з verifier, які не дае таго самага challenge, завяршаецца памылкай invalid_grant. Паспяховае параўнанне PKCE яшчэ не завяршае праверку: код павінен належаць гэтаму кліенту, адпавядаць redirect URI і не быць выкарыстаным раней.

Асобна закрыйце магчымасць абысці PKCE праз выдаленне challenge з пачатковага запыту. Калі ў запыце на токен з'явіўся code_verifier, а код быў выдадзены без code_challenge, сервер павінен адхіліць абмен. Для публічнага кліента, якому патрабуецца PKCE, запыт аўтарызацыі без challenge таксама адхіляецца. Падтрымку механізму кліент можа вызначыць праз метаданыя сервера, у тым ліку code_challenge_methods_supported, або праз іншы прадугледжаны серверам спосаб.

Захоўвайце токены з улікам іх уласнай рызыкі

Пасля выдачы токена праверка PKCE ўжо скончылася. Той, хто атрымаў звычайны bearer access token, можа выкарыстаць яго без verifier, таму токены трэба перадаваць па абароненым злучэнні і захоўваць у сховішчы, прыдатным для платформы. Для сервернай праграмы гэта можа быць сховішча з шыфраваннем і абмежаваным доступам; для настольнай — абароненае сховішча аперацыйнай сістэмы. Токены і verifier не павінны трапляць у часопісы запытаў.

Запытвайце толькі патрэбныя scope і абмяжоўвайце токен адпаведнымі рэсурсамі: гэта скарачае шкоду ад яго ўцечкі. Калі публічнаму кліенту выдаецца refresh token, сервер павінен прывязаць яго да адпраўніка або выкарыстоўваць ратацыю, каб выяўляць паўторнае выкарыстанне. Гэтыя меры абараняюць ужо выдадзеныя ўліковыя даныя, тады як PKCE кантралюе абмен кода на іх.

Чытайце таксама:

• WhatsApp замяніў шасцізначны PIN паролем — праверце абарону нанова
• OAuth у MCP наладжаны — але 96,6% сервераў усё роўна маюць адну дзірку
• WordPress 7.1.2 закрывае захоп сайта — выпраўленне дайшло нават да 4.7