Նույնականացում և թույլտվություններ

01Session-ներ ընդդեմ token-ների

Մուտքից հետո սերվերը պետք է ճանաչի ձեզ հաջորդ հարցման ժամանակ։ Session-ների դեպքում սերվերը պահում է ձեր մուտքի վիճակը (Redis-ում կամ տվյալների բազայում) և բրաուզերին տալիս է պատահական session id cookie-ի մեջ՝ ինչպես հանդերձարանի համարանիշը։ Համարանիշն ինքնին ոչինչ չի նշանակում, սերվերն է այն փնտրում իր մոտ։ Դուրս գալը հեշտ է՝ պարզապես ջնջում ես session-ը։ Token-ների դեպքում սերվերը կլիենտին տալիս է ստորագրված token, որն ինքն իր մեջ պարունակում է claim-ներ, օրինակ՝ օգտատիրոջ id և վավերականության ժամկետ, իսկ սերվերը ոչինչ չի փնտրում, այլ ստուգում է ստորագրությունը։ Session-ները լավագույն լռելյայն ընտրությունն են ձեր սեփական դոմենի վեբկայքերի համար։ Token-ները հարմար են մոբայլ հավելվածների, երրորդ կողմի կլիենտների և ծառայություն-ծառայություն կանչերի համար։ Շատ պրոդուկտներ օգտագործում են երկուսն էլ։

• Session cookie՝ HttpOnly, Secure, SameSite=Lax (կամ Strict), անգործության կարճ timeout։
• Մուտքի պահին վերագեներացրեք session id-ն՝ session fixation-ից պաշտպանվելու համար։
• Cookie-ներին պետք է CSRF պաշտպանություն, իսկ header-ներում փոխանցվող bearer token-ներին՝ XSS պաշտպանություն։

02JWT՝ access token-ներ, refresh token-ներ և չեղարկում

JWT-ն (JSON Web Token) բաղկացած է երեք մասից՝ header, claim-ներով payload և ստորագրություն։ Payload-ը կարող է կարդալ ցանկացած մեկը, ուստի երբեք գաղտնիքներ մի դրեք այնտեղ․ ստորագրությունը միայն ապացուցում է, որ այն չի փոփոխվել։ API կանչերի համար օգտագործեք կարճատև access token (5-ից 15 րոպե), իսկ նոր access token-ներ ստանալու համար՝ երկարատև refresh token, որը պահվում է ապահով տեղում։ Rotate արեք refresh token-ները՝ յուրաքանչյուր օգտագործում թողարկում է նորը և անվավեր դարձնում հինը։ Եթե հին refresh token-ը երբևէ նորից օգտագործվի, ենթադրեք, որ այն գողացվել է, և չեղարկեք token-ների ամբողջ «ընտանիքը»։ Քանի որ JWT-ները վավեր են մինչև ժամկետի ավարտը, չեղարկումը լրացուցիչ աշխատանք է պահանջում՝ token id-ների (jti) denylist Redis-ում, token-ի տարբերակ օգտատիրոջ վրա կամ օգտատիրոջ կրկնակի ստուգում յուրաքանչյուր հարցման ժամանակ։ Երբ token-ները ստուգում են մի քանի ծառայություններ, նախընտրեք ասիմետրիկ ստորագրություն (RS256 կամ EdDSA) և միշտ ստուգեք alg-ը, iss-ը, aud-ը և exp-ը։

1// Verify an access token (jose library)
2import { jwtVerify, createRemoteJWKSet } from 'jose';
3 
4const jwks = createRemoteJWKSet(new URL('https://auth.example.com/.well-known/jwks.json'));
5 
6export async function verifyAccessToken(token: string) {
7  const { payload } = await jwtVerify(token, jwks, {
8    issuer: 'https://auth.example.com',
9    audience: 'api.example.com',
10    algorithms: ['RS256'],
11  });
12  if (await denylist.has(payload.jti as string)) throw new Error('Token revoked');
13  return payload;
14}

03OAuth2, OpenID Connect և սոցիալական մուտք

OAuth2-ը պատվիրակված հասանելիության ստանդարտ է՝ օգտատերը թույլ է տալիս հավելվածին գործել իր անունից՝ առանց իր գաղտնաբառը տալու։ OpenID Connect-ը (OIDC) դրա վրա կառուցված շերտ է, որն ավելացնում է ինքնությունը՝ ID token, որն ասում է, թե ով է օգտատերը։ «Sign in with Google»-ը կամ «Sign in with Apple»-ը հենց OIDC է։ Վեբ և մոբայլ հավելվածների համար օգտագործեք Authorization Code flow-ը PKCE-ով (Proof Key for Code Exchange), որը պաշտպանում է կոդը որսալուց․ հին Implicit flow-ն այլևս deprecated է։ Միշտ ստուգեք state պարամետրը CSRF-ի դեմ, ստուգեք ID token-ի ստորագրությունը, issuer-ը, audience-ը և nonce-ը, իսկ սոցիալական հաշիվները կապեք պրովայդերի կայուն subject id-ով, ոչ թե միայն email-ով։ iOS հավելվածները, որոնք առաջարկում են երրորդ կողմի սոցիալական մուտք, պետք է առաջարկեն նաև գաղտնիությանն ուղղված տարբերակ, օրինակ՝ Sign in with Apple (App Store guideline 4.8)։

04Գաղտնաբառեր, OTP և 2FA

Երբեք մի պահեք գաղտնաբառեր, պահեք hash-եր։ Օգտագործեք Argon2id (OWASP նվազագույնը՝ 19 MiB հիշողություն, 2 իտերացիա, parallelism 1) կամ bcrypt՝ 10 կամ ավելի cost-ով․ հաշվի առեք, որ bcrypt-ն օգտագործում է միայն առաջին 72 բայթը։ Ֆրեյմվորքներն այդ ամենն անում են ձեր փոխարեն՝ Laravel-ի Hash facade-ը կամ Node-ում argon2 փաթեթը։ Նոր գաղտնաբառերը ստուգեք արտահոսած գաղտնաբառերի հայտնի ցուցակներով և սահմանափակեք մուտքի փորձերի քանակը։ SMS-ով կամ email-ով մեկանգամյա գաղտնաբառերը հարմար են այն շուկաների համար, որտեղ ամեն ինչ հեռախոսով է․ գեներացրեք պատահական 6-նիշանոց կոդ, պահեք միայն դրա hash-ը կարճ ժամկետով (մոտ 5 րոպե), թույլ տվեք մի քանի փորձ և սահմանափակեք ուղարկումները ըստ հեռախոսահամարի և IP-ի, որպեսզի կանխեք SMS-ի ծախսերի չարաշահումը։ Երկգործոն նույնականացումն ավելացնում է երկրորդ ապացույց՝ TOTP հավելվածներ, passkey-ներ (WebAuthn) կամ SMS՝ որպես ավելի թույլ պահեստային տարբերակ։ Պարտադրեք 2FA աշխատակիցների և ադմինների համար։

1// Laravel: OTP verification with rate limiting
2$key = 'otp:'.$request->phone;
3if (RateLimiter::tooManyAttempts($key, 5)) {
4    abort(429, 'Too many attempts, try again later.');
5}
6RateLimiter::hit($key, 600);
7 
8$otp = OtpCode::where('phone', $request->phone)
9    ->where('expires_at', '>', now())
10    ->latest()->first();
11 
12if (! $otp || ! Hash::check($request->code, $otp->code_hash)) {
13    throw ValidationException::withMessages(['code' => 'Invalid or expired code.']);
14}
15$otp->delete();
16RateLimiter::clear($key);

05Դերեր, իրավունքներ և API բանալիներ

RBAC-ը՝ դերերի վրա հիմնված հասանելիության կառավարումը, օգտատերերին տալիս է դերեր (owner, manager, cashier), իսկ դերերը կրում են իրավունքներ (orders.refund, menu.edit)։ Կոդում ստուգեք իրավունքները, ոչ թե դերերի անունները․ «կարող է վերադարձնել գումարը» ստուգումը դիմանում է նոր դերերի ավելացմանը, իսկ «մենեջեր է»-ն՝ ոչ։ Ստուգումները պահեք սերվերում՝ մեկ տեղում, օրինակ՝ Laravel-ի policy-ներում և gate-երում կամ NestJS-ի guard-երում, իսկ UI-ում կոճակները թաքցրեք միայն որպես հարմարություն։ Multi-tenant հավելվածներում յուրաքանչյուր ստուգում ներառում է նաև tenant-ը՝ A ընկերության մենեջերը B ընկերությունում որևէ իրավունք չունի։ Մեքենայական կլիենտների համար թողարկեք scope-երով API բանալիներ՝ գեներացրեք երկար պատահական բանալի, ցույց տվեք այն մեկ անգամ, պահեք միայն դրա hash-ը, ավելացրեք տեսանելի prefix՝ այն նույնականացնելու համար (օրինակ՝ live_ կամ test_), և աջակցեք ժամկետի ավարտին, rotation-ին և յուրաքանչյուր բանալու rate limit-ին։ Գրանցեք, թե ով որ բանալին է օգտագործել։

06Անվտանգ լռելյայն կարգավորումների ստուգացանկ

Auth-ի բագերի մեծ մասը գալիս է մանրուքներից։ Cookie-ները սահմանեք HttpOnly-ով, որպեսզի JavaScript-ը չկարողանա դրանք կարդալ, Secure-ով, որպեսզի դրանք փոխանցվեն միայն HTTPS-ով, SameSite=Lax կամ Strict՝ CSRF-ի դեմ, և նեղ Path-ով։ Հնարավորության դեպքում session cookie-ների համար օգտագործեք __Host- prefix-ը։ «Անհայտ օգտատեր» և «սխալ գաղտնաբառ» դեպքերի համար վերադարձրեք նույն սխալը, որպեսզի խուսափեք հաշիվների enumeration-ից։ Սահմանափակեք մուտքի, OTP-ի և գաղտնաբառի վերականգնման հարցումները։ Վերականգնման հղումները դարձրեք մեկանգամյա և կարճատև։ Գրանցեք անվտանգության իրադարձությունները (մուտքեր, անհաջող փորձեր, դերերի փոփոխություններ, impersonation) և ահազանգեք կտրուկ աճերի դեպքում։ Սապորտի impersonation-ի համար սահմանեք ժամանակային սահմանափակում, պահանջեք պատճառ և աուդիտ արեք այն։

1Set-Cookie: __Host-session=9f8c...; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=7200

07Որտեղ են ապրում token-ները՝ բրաուզերներ, BFF pattern և մոբայլ պահոց

Ցանկացած token, որը JavaScript-ը կարող է կարդալ, XSS սխալը կարող է գողանալ։ Ահա թե ինչու access և refresh token-ները localStorage-ում պահելը ռիսկային է single-page հավելվածի համար։ Backend-for-Frontend (BFF) pattern-ը token-ները ամբողջությամբ հանում է բրաուզերից. ձեր դոմենի վրա բարակ սերվերը կատարում է OAuth flow-ը, token-ները պահում է սերվերում և բրաուզերին տալիս է միայն HttpOnly, Secure, SameSite session cookie։ API կանչերն անցնում են BFF-ով, որը կցում է access token-ը։ Մոբայլում հենվելու cookie jar չկա, ուստի refresh token-ները պահեք պլատֆորմի անվտանգ պահոցում՝ iOS-ում Keychain, Android-ում Keystore-ով ապահովված պահոց, երբեք պարզ preferences-ում։ OAuth 2.0 Security Best Current Practice-ը (RFC 9700, հունվար 2025) նաև խորհուրդ է տալիս հնարավորության դեպքում sender-constrained token-ներ, օրինակ՝ DPoP (RFC 9449), որը token-ը կապում է client-ի մոտ գտնվող բանալու հետ, այնպես որ միայն գողացված token-ն անօգուտ է։

• SPA ձեր սեփական դոմենում՝ session cookie կամ BFF, ոչ թե localStorage։
• Մոբայլ՝ անվտանգ պահոց գումարած refresh token-ի ռոտացիա՝ կապված սարքի հետ։
• Ծառայությունից ծառայություն՝ client credentials կամ mTLS, կարճատև token-ներ։

08Passkey-ներն ու WebAuthn-ը ներսից

Passkey-ը բանալիների զույգ է, որը օգտատիրոջ սարքը ստեղծում է մեկ կայքի համար։ Մասնավոր բանալին երբեք դուրս չի գալիս սարքից կամ օգտատիրոջ password manager-ից. սերվերը պահում է միայն հանրային բանալին։ Մուտք գործելու համար սերվերը ուղարկում է պատահական challenge, սարքը խնդրում է մատնահետք, դեմք կամ PIN և ստորագրում է challenge-ը։ Սերվերը ստուգում է ստորագրությունը պահված հանրային բանալիով։ Ամենակարևորը՝ բրաուզերը ստորագրվողի մեջ ներառում է origin-ը, ուստի նման տեսք ունեցող դոմենի վրա կեղծ կայքը չի կարող վավեր ստորագրություն ստանալ. passkey-ները դիմացկուն են phishing-ին այնպես, ինչպես SMS կոդերն ու TOTP-ն չեն։ Ձեր կայքը relying party-ն է, որը նույնականացվում է RP ID-ով, օրինակ՝ example.com։ Երկու կողմում էլ օգտագործեք պահպանվող գրադարան, պահեք վերականգնման առնվազն մեկ ուղի և թույլ տվեք օգտատերերին գրանցել մի քանի passkey։

1// Browser, using @simplewebauthn/browser
2import { startAuthentication } from '@simplewebauthn/browser';
3 
4const optionsJSON = await api.post('/webauthn/login/options'); // fresh, single-use challenge
5const assertion = await startAuthentication({ optionsJSON });
6await api.post('/webauthn/login/verify', assertion);
7 
8// Server (@simplewebauthn/server verifyAuthenticationResponse) must check:
9// expected challenge, expected origin and RP ID, the signature against the
10// stored public key, and user verification if your policy requires it.

09Timing հարձակումներ, enumeration և credential stuffing

Հարձակվողները սովորում են փոքրիկ տարբերություններից։ Եթե «անհայտ email»-ը վերադառնում է 5 մվ-ում, իսկ «սխալ գաղտնաբառը»՝ 80 մվ-ում, որովհետև միայն երկրորդն է hash հաշվում, նրանք կարող են ցուցակել, թե որ հաշիվներն են գոյություն ունենում։ Անհայտ օգտատերերի համար գործարկեք կեղծ hash և վերադարձրեք նույն հաղորդագրությունը։ Գաղտնիքները, ինչպիսիք են API key-երը, reset token-ները և webhook-ների ստորագրությունները, համեմատեք հաստատուն ժամանակի ֆունկցիաներով՝ PHP-ում hash_equals, Node-ում crypto.timingSafeEqual, երբեք ===-ով։ Credential stuffing-ը՝ այլ կայքերից արտահոսած email-ի և գաղտնաբառի զույգերի փորձարկումը, login ձևերի վրա ամենատարածված հարձակումն է։ Պաշտպանվեք շերտերով. rate limit-ներ ըստ հաշվի և ըստ IP-ի, ստուգում արտահոսած գաղտնաբառերի դեմ (Have I Been Pwned-ի range API-ն օգտագործում է k-anonymity, այնպես որ ուղարկում եք SHA-1 hash-ի միայն առաջին հինգ նիշը), CAPTCHA կասկածելի օրինաչափություններից հետո և ահազանգեր login-ի ձախողումների կտրուկ աճի դեպքում։ Հաշվի կոշտ արգելափակումը կարող է չարաշահվել՝ իրական օգտատերերին դուրս թողնելու համար, ուստի նախընտրեք աստիճանաբար աճող ուշացումներ։

1import { createHmac, timingSafeEqual } from 'node:crypto';
2 
3export function isValidSignature(rawBody: Buffer, headerHex: string, secret: string) {
4  const expected = createHmac('sha256', secret).update(rawBody).digest();
5  const received = Buffer.from(headerHex, 'hex');
6  // timingSafeEqual throws on different lengths, so check that first
7  return received.length === expected.length && timingSafeEqual(received, expected);
8}

10Authorization դերերից այն կողմ՝ ABAC, ReBAC և ցուցակների ֆիլտրում

Դերերը պատասխանում են «ինչ տեսակի օգտատեր է սա» հարցին, բայց իրական կանոնները հաճախ կախված են ավելիից։ Attribute-based access control-ը (ABAC) ավելացնում է պայմաններ. մենեջերը կարող է վերադարձնել միայն իր մասնաճյուղի պատվերները և միայն մինչև որոշակի սահման։ Relationship-based access control-ը (ReBAC), որը տարածվեց Google-ի Zanzibar հոդվածով և իրականացված է OpenFGA-ում և SpiceDB-ում, թույլտվությունները մոդելավորում է որպես գրաֆ. օգտատերը կարող է խմբագրել փաստաթուղթը, որովհետև պատկանում է այն թիմին, որին պատկանում է դրա պանակը։ Policy engine-ները, օրինակ՝ OPA-ն կամ Cedar-ը, կանոնները պահում են կոդից դուրս։ Ամենադժվարը ցուցակներն են. յուրաքանչյուր տող բեռնելուց հետո ստուգելը կոտրում է pagination-ը և արտահոսեցնում քանակները։ Փոխարենը authorization-ը տեղափոխեք հարցման մեջ՝ որպես scope, որը ավելացնում է tenant-ի, մասնաճյուղի կամ սեփականության պայմաններ, որպեսզի բազան վերադարձնի միայն այն տողերը, որոնք օգտատերը կարող է տեսնել։ Թեստավորեք երկու ուղղությամբ էլ. թույլատրված օգտատերերը տեսնում են տվյալները, իսկ մնացած բոլորը ստանում են 404։