// docs / baas security / auth0 hardening

Кантрольны спіс бяспекі Auth0: 22 пункты

Auth0 — гэта платформа ідэнтыфікацыі-як-сэрвіс з велізарнай паверхняй — праграмы, API (рэсурсныя серверы), арандатары, дзеянні, правілы (састарэлыя), злучэнні і гранты. Няправільная наладка любога з іх — гэта абыход аўтэнтыфікацыі. Гэты кантрольны спіс — аўдыт з 22 пунктаў па праграмах, спісах дазволу callback / logout, токенах і ратацыі refresh, карыстальніцкіх дзеяннях, RBAC, выяўленні анамалій і пастаянным маніторынгу. Кожны пункт можна праверыць у панэлі Auth0 менш чым за 10 хвілін.

Для эквівалентнага кантрольнага спісу па Clerk гл. Кантрольны спіс бяспекі Clerk. Для фону пра тое, чаму няправільныя налады пласта ідэнтыфікацыі — гэта сляпыя плямы ШІ-інструментаў, гл. Чаму ШІ-інструменты кадавання пакідаюць прабелы ў бяспецы.

Тып праграмы і тыпы грантаў

Тып праграмы і ўключаныя тыпы грантаў — гэта налады з самым высокім уплывам у Auth0. Іх няправільнае выкарыстанне адкрывае класы атак, якія ніякі аб'ём фронтэнд-кода не закрые.

Выкарыстоўвайце Application Type = Single Page Application для праграм толькі для браўзера і Regular Web Application для серверна-рэндзераных праграм. Няправільны тып дазваляе няправільныя тыпы грантаў — напрыклад, Regular Web App з SPA-грантам уключае Implicit flow без PKCE, які раскрывае токены праз фрагменты URL.
Адключыце тып гранта Implicit на кожнай праграме. Dashboard → Application → Advanced Settings → Grant Types → зніміце галачку Implicit. Implicit flow вяртае токены ў фрагментах URL, дзе яны лагуюцца ў гісторыі браўзера і аналітыцы. Выкарыстоўвайце Authorization Code з PKCE замест гэтага.
Адключыце грант Password, калі ў вас няма задакументаванай патрэбы. Грант Resource Owner Password Credentials (ROPC) патрабуе ад вас самастойна апрацоўваць паролі карыстальнікаў — перашкаджаючы большасці таго, за што вы купілі Auth0. Адключыце яго, калі вы не інтэгруеце састарэлую сістэму.
Уключыце Authorization Code з PKCE на кожным публічным кліенце. Dashboard → Advanced Settings → OAuth → JsonWebToken Signature Algorithm = RS256, OIDC Conformant = уключана. PKCE патрабуецца для мабільных праграм і SPA для прадухілення перахопу кода.

Спісы дазволу callback і logout URL

Адкрытыя перанакіраванні на шляху OAuth callback — гэта прымітыў крадзяжу токена. Спіс дазволу Auth0 — гэта ваша адзіная абарона.

Усталюйце Allowed Callback URLs на дакладны шлях прадукцыйнага callback — без падстаноўных знакаў. https://yourapp.com/callback, а не https://yourapp.com/*. Падстаноўныя callback дазваляюць зламыснікам перанакіроўваць токены на адвольныя падшляхі вашага дамена.
Усталюйце Allowed Logout URLs на канчатковы спіс. Тое ж правіла: толькі відавочныя URL. Адкрытае logout-перанакіраванне дазваляе зламыснікам ствараць фішынгавыя старонкі, якія выглядаюць як стан пасля вашага logout.
Усталюйце Allowed Web Origins толькі на ваш прадукцыйны origin. Выкарыстоўваецца для маўклівай аўтэнтыфікацыі (абнаўленне токена праз схаваны iframe). Падстаноўны origin дазваляе старонкам зламысніка выконваць маўклівую аўтэнтыфікацыю супраць вашага арандатара.
Усталюйце Allowed CORS origins для API-эндпоінтаў, а не для праграмы. Tenant Settings → Advanced → Allowed CORS origins. Па змаўчанні пуста (абмежавана); дадавайце толькі відавочныя origin, якімі вы кантралюеце.

Токены і ратацыя refresh

Тэрмін дзеяння токена, ратацыя refresh і алгарытм подпісу вызначаюць радыус выбуху любой уцечкі токена.

Уключыце ратацыю Refresh Token. Application → Refresh Token Settings → Rotation. Кожны refresh выдае новы refresh-токен і анулюе стары. У спалучэнні з абсалютным тэрмінам дзеяння гэта стрымлівае крадзеж токенаў.
Усталюйце Refresh Token Reuse Interval у 0 (або як мага ніжэй, як дазваляе ваша талерантнасць да паўтораў). Інтэрвал паўторнага выкарыстання дазваляе выкарыстоўваць токен двойчы ў адным акне — адключыце яго, калі ў вас няма канкрэтнай прычыны яго трымаць.
Усталюйце Absolute Refresh Token Expiry на 14-30 дзён, а не бясконца. Application → Refresh Token Expiration → Absolute Expiration. Auth0 па змаўчанні выкарыстоўвае толькі Inactivity, што азначае, што неактыўная сесія можа захоўвацца гадамі.
Усталюйце JWT Signature Algorithm на RS256. Application → Advanced → OAuth → JsonWebToken Signature Algorithm. RS256 выкарыстоўвае асіметрычны подпіс, таму кліент не можа падрабіць токены. Ніколі не выкарыстоўвайце HS256 для праграм, скіраваных на кліента.
Правярайце патрабаванні aud і iss на кожным JWT, які атрымлівае ваш API. Выкарыстоўвайце афіцыйны SDK Auth0 на серверным баку — ён правярае гэта аўтаматычна. Самаробны парсінг JWT звычайна прапускае валідацыю аўдыторыі, што з'яўляецца абыходам аўтэнтыфікацыі.

Дзеянні і карыстальніцкі код

Дзеянні Auth0 (і састарэлыя Правілы) запускаюцца на серверы пры ўваходзе і іншых падзеях жыццёвага цыклу. Яны маюць доступ да ўсяго кантэксту запыту. Небяспечны код тут — гэта ўразлівасць на ўсё арандатара.

Ніколі не лагуйце event.user або event.transaction як цэлы аб'ект. Яны змяшчаюць адрасы электроннай пошты, IP-адрасы і іншы PII. Выкарыстоўвайце толькі палявое лагіраванне і лагуйце толькі тое, што вам трэба.
Выкарыстоўвайце сховішча сакрэтаў для любога API-ключа або URL вэбхука. Actions → Edit → Secrets. Ніколі не ўбудоўвайце API-ключ як радковы літарал у код дзеяння — код бачны любому з доступам да рэдактара дзеянняў на арандатары.
Правярайце ўваходы перад захаваннем іх як user_metadata або app_metadata. Самаабслугоўваючае дзеянне, якое запісвае event.body.name у user.user_metadata.display_name — гэта вектар захаванага XSS, калі ваш фронтэнд рэндзерыць гэтае поле без экранавання.

RBAC і рэсурсныя серверы

Калі вы выкарыстоўваеце Auth0 RBAC, картаграфаванне роля-дазвол — гэта ваш пласт аўтарызацыі. Зрабіце гэта няправільна, і любы аўтэнтыфікаваны карыстальнік можа дасягнуць адмінскіх эндпоінтаў.

Вызначайце рэсурсныя серверы (API) відавочна ў панэлі Auth0, а не на хаду. Кожны API мае ідэнтыфікатар (audience), скоупы і налады подпісу. Без зарэгістраванага API ўсе токены выдаюцца для няяўнага "Auth0 Management API" — няправільная аўдыторыя.
Наладзьце дазволы на API і патрабуйце іх у сваім кодзе з патрабаваннем scope. Не правярайце прыналежнасць да ролі ў логіцы вашай праграмы; правярайце скоупы ў access-токене. Скоупы — гэта OAuth-натыўны механізм аўтарызацыі.
Тэстуйце, што аўтэнтыфікаваны карыстальнік без неабходнай ролі / скоупа не можа дасягнуць прывілеяваных эндпоінтаў. Увайдзіце як звычайны карыстальнік, паспрабуйце выклікаць POST /api/admin/users/delete. Адказ павінен быць 403.

Выяўленне анамалій і логі арандатара

Auth0 выдае падзеі з высокім сігналам. Наладзьце іх для папярэджвання вашай каманды, а не проста сядзець у буферы логаў.

Уключыце Attack Protection: Bot Detection, Brute Force, Suspicious IP Throttling. Dashboard → Security → Attack Protection. Кожны адключаны па змаўчанні на бясплатных тарыфах; уключыце ўсё для прадакшэна.
Стрымайце логі арандатара ў SIEM або вашы логі праграмы. Dashboard → Monitoring → Streams. Auth0 захоўвае логі на працягу 30 дзён на большасці тарыфаў; даўжэйшае захаванне патрабуе струмень у вашу ўласную сістэму.
Папярэджвайце пра ўсплёскі fcoa (няўдалая міждаменная аўтэнтыфікацыя) і fp (няўдалы ўваход). Усплёск гэтых у кароткім акне — гэта credential stuffing. Накіроўвайце ў ваш канал дзяжурства.

Наступныя крокі

Запусціце сканаванне FixVibe супраць вашага прадукцыйнага URL — праверка baas.clerk-auth0 пазначае кліенцкія сакрэты Auth0, пастаўленыя ў JavaScript, і іншыя класы раскрыцця пастаўшчыка ідэнтыфікацыі. Для эквівалентнага на Clerk гл. Кантрольны спіс бяспекі Clerk. Для агульнага агляду па пастаўшчыках BaaS прачытайце Сканер няправільных налад BaaS.