Ի՞նչ է նույնականացումը։ Մուտքեր, սեսիաներ և OAuth պարզ բացատրությամբ

Նույնականացումը այն է, թե ինչպես հավելվածը հաստատում է օգտատիրոջ ով լինելը։ Սովորաբար դա ստուգվում է ինչ-որ բանով, որ օգտատերը գիտի (գաղտնաբառ), ունի (կոդ, որն ուղարկվում է իր հեռախոսին կամ էլփոստին) կամ ինչ-որ վստահելի այլ ծառայությունից եկած ինքնություն (օրինակ՝ «Sign in with Google»)։ Երբ օգտատերը նույնականացված է, հավելվածը նրան հիշում է սեսիայի կամ թոքենի միջոցով, որպեսզի յուրաքանչյուր էջի վրա նորից մուտք չգործի։ Այն, թե ինչ է թույլատրված անել այդ հայտնի օգտատիրոջը, առանձին քայլ է, որը կոչվում է լիազորում (authorization)։

Ինչու է դա կարևոր, երբ կառուցում եք AI-ով

Մուտք ավելացնելը AI կառուցիչին ամենատարածված խնդրանքներից մեկն է և նաև ամենահեշտը, որ նրբորեն սխալ լինի։ Մուտքի էջը պարզ է ստեղծել։ Դժվարը այն ամենն է, ինչ նրա շուրջն է․

Արդյո՞ք գաղտնաբառերը պահվում են ապահով։
Արդյո՞ք յուրաքանչյուր մասնավոր էջ և API վերջնակետ իսկապես ստուգում է, թե ով է հարցնում։
Կարո՞ղ է մուտք գործած հաճախորդը տեսնել մեկ այլ հաճախորդի տվյալները՝ URL-ում թիվը փոխելով։
Ի՞նչ է լինում, երբ ինչ-որ մեկը մոռանում է գաղտնաբառը։

Հավելվածը կարող է արտաքինից լրիվ ապահով թվալ, և միաժամանակ ձախողել այս բոլորը։ Աշխատող մասերը հասկանալը թույլ է տալիս ճիշտ հարցեր տալ և ճիշտ բաներ ստուգել։

Ամենօրյա անալոգիա

Պատկերացրեք հյուրանոց մուտք գործելը։

Փոստային գրասեղանի մոտ դուք ցույց եք տալիս ձեր փաստաթուղթը։ Դա նույնականացում է՝ ապացույց, թե ով եք։ Ընդունողը ձեզ տալիս է բանալի-քարտ։ Այդ քարտը ձեր սեսիան է. մնալու ամբողջ ընթացքում ձեզ չի պետք նորից ցույց տալ փաստաթուղթ, պարզապես թակում եք քարտով։

Քարտը բացում է ձեր սենյակը, մարզասրահը և ձեր հարկի վերելակը, բայց ոչ ուրիշ հյուրերի սենյակները կամ անձնակազմի սենյակը։ Դա լիազորում է՝ ինչին է ձեր ինքնությունը թույլատրում մուտք։ Եթե քարտը կորցնեք, հյուրանոցը այն կարող է ապաակտիվացնել գրասեղանում (սեսիայի չեղարկում)։ Երբ հեռանաք, այն կդադարի աշխատել (դուրս գալ կամ ժամկետի ավարտ)։

Մեկ այլ վստահելի գործընկերոջից եկած նամակով հյուրանոցը ընդունում է ձեր ինքնությունը՝ «սա այս մարդն է» ասելով, փոխանակ ինքը ստուգի ձեր փաստաթուղթը։ Այսպես է աշխատում «Sign in with Google»-ը։

Մուտքի հիմնական եղանակները

Եղանակ	Ինչպես է աշխատում	Առավելություններ	Թերություններ
Էլփոստ + գաղտնաբառ	Օգտատերը ընտրում է գաղտնաբառ, հավելվածը պահում է դրա հեշը	Ծանոթ է, արտաքին կախվածություն չկա	Պետք է ապահով պահել հեշերը և կարգավորել վերականգնումը
Մագիկ հղում / միանգամյա կոդ	Հավելվածը էլփոստով ուղարկում է հղում կամ կոդ, որով օգտատերը մուտք է գործում	Գաղտնաբառեր չկան, որ արտահոսեն կամ մոռացվեն	Կախված է էլփոստի առաքումից, մուտքը ավելի դանդաղ է
Սոցիալական մուտք (OAuth / OpenID Connect)	Օգտատերը մուտք է գործում Google-ով, Apple-ով, GitHub-ով և այլն	Արագ օգտատերերի համար, դուք գաղտնաբառ չեք պահում	Յուրաքանչյուր մատակարարի հետ կարգավորում, օգտատերերը առանց այդ հաշիվների
Հոստինգային նույնականացման մատուցող	Ծառայություն, ինչպիսին Clerk-ը, Auth0-ն կամ Supabase Auth-ը, կառավարում է գրանցումը, մուտքը և վերականգնումը	Ձեզ համար պակաս անվտանգության աշխատանք	Ամսական վճար մեծ մասշտաբում, ևս մեկ կախվածություն
Բազմաքայլ նույնականացում (MFA / 2FA)	Երկրորդ ստուգում առաջինից հետո, օրինակ՝ նույնականացման հավելվածի կոդ	Շատ ավելի դժվար է կոտրել	Մի փոքր ավելի շատ քայլ

Ինչպես պետք է պահվեն գաղտնաբառերը

Ապահով հավելվածը երբեք չի պահում ձեր իրական գաղտնաբառը։ Փոխարենը այն պահում է հեշ` միակողմանի ֆունկցիայի արդյունքը, որը գաղտնաբառը վերածում է ֆիքսված տողի։ Երբ մուտք եք գործում, հավելվածը հեշավորում է այն, ինչ գրել եք, և արդյունքը համեմատում պահված հեշի հետ։

Երկու մանրամասն է դա անվտանգ դարձնում․

Աղ (salt)՝ պատահական արժեք, որ ավելացվում է յուրաքանչյուր գաղտնաբառին հեշավորումից առաջ, այնպես որ երկու մարդ նույն գաղտնաբառով ունենում են տարբեր հեշեր, և նախապես հաշվարկված աղյուսակները անօգուտ են։
Դանդաղ ալգորիթմ, որ նախատեսված է գաղտնաբառերի համար՝ օրինակ՝ Argon2, bcrypt կամ scrypt։ Ընդհանուր նպատակի հեշերը, ինչպիսիք են MD5-ը կամ SHA-256-ը, առանձին վերցրած շատ արագ են․ հարձակվողները կարող են միլիարդավոր գուշակություններ փորձել։

Հեշավորումը նույնը չէ, ինչ կոդավորումը։ Կոդավորված տվյալը կարելի է վերծանել բանալիով, իսկ գաղտնաբառի հեշը նախատեսված է, որ ընդհանրապես չվերծանվի։

Սեսիաներ ընդդեմ թոքենների

Մուտքից հետո հավելվածը պետք է ճանաչի ձեզ յուրաքանչյուր հարցման ժամանակ։ Կան երկու տարածված մոտեցում։

	Սեսիա (cookie)	Թոքեն (օր.՝ JWT)
Ինչ է պահում բրաուզերը	Պատահական սեսիայի ID cookie-ում	Ստորագրված թոքեն՝ օգտատիրոջ տեղեկությամբ և ժամկետով
Որտեղ է գտնվում մուտքի վիճակը	Սերվերում, բազայում կամ պահեստում	Հենց թոքենի մեջ
Դուրս գրել բոլոր վայրերից	Հեշտ է՝ ջնջել սեսիան սերվերում	Ավելի դժվար է՝ թոքենը վավեր է մնում մինչև ժամկետի ավարտը, եթե չպահեք արգելափակման ցանկ
Տիպիկ օգտագործում	Ավանդական վեբ հավելվածներ	API-ներ, բջջային հավելվածներ, ծառայություններ, որ խոսում են իրար հետ

Cookie-ների համար երեք կարգավորում է կարևոր․ HttpOnly (էջի JavaScript-ը չի կարող կարդալ cookie-ն), Secure (ուղարկվում է միայն HTTPS-ով) և SameSite (սահմանափակում է դրա ուղարկումը այլ կայքերից եկող հարցումներում)։ Թոքենները բրաուզերի localStorage-ում պահելը տարածված է, բայց դրանք բացահայտում է էջում աշխատող ցանկացած սկրիպտի համար։

OAuth 2.0-ը պատվիրակված լիազորման ստանդարտ է․ այն թույլ է տալիս հավելվածին սահմանափակ մուտք ստանալ ձեր հաշվին մեկ այլ ծառայությունում՝ օրինակ՝ կարդալ ձեր Google Calendar-ը՝ առանց երբևէ տեսնելու ձեր Google գաղտնաբառը։ Դուք ուղղորդվում եք Google, հաստատում եք կոնկրետ թույլտվություններ (որոնք կոչվում են scopes), և Google հավելվածին տալիս է թոքեն միայն այդ թույլտվությունների համար։

OAuth-ը միայնակ նախատեսված էր մուտք տալու համար, ոչ թե ասելու, թե դուք ով եք։ OpenID Connect (OIDC)-ը OAuth 2.0-ի վրա դրված շերտ է, որ ավելացնում է ինքնություն, և հենց դա է օգտագործվում «Sign in with Google» կամ «Sign in with Apple» կոճակների համար։ Այն կարգավորելու համար հավելվածը գրանցում եք մատակարարի մոտ և ստանում client ID-ն ու client secret-ը․ գաղտնիքը մնում է ձեր սերվերում։

Օրինակ աշխատանքում․ մուտք հաճախորդի պորտալի համար

Նշենք, որ կառուցում եք պորտալ, որտեղ դիզայն գործակալության հաճախորդները տեսնում են իրենց նախագծերն ու հաշիվ-ֆակտուրաները։

Նույնականացում․ հաճախորդները մուտք են գործում էլփոստով և մագիկ հղումով, այնպես որ գաղտնաբառեր կառավարելու կարիք չկա։ Գործակալության աշխատակիցները մուտք են գործում Google Workspace հաշիվներով։
Դերեր․ յուրաքանչյուր օգտատեր ունի դեր՝ client կամ staff։
Լիազորման կանոններ․

Գործողություն	Հաճախորդ	Աշխատակից
Տեսնել իր ընկերության նախագծերը	Այո	Այո
Տեսնել այլ ընկերությունների նախագծերը	Ոչ	Այո
Ֆայլ վերբեռնել նախագծում	Միայն սեփական նախագծերում	Այո
Նշել հաշիվ-ֆակտուրան որպես վճարված	Ոչ	Այո

Որտեղ է կիրառվում․ սերվերում, յուրաքանչյուր հարցման համար։ Սերվերը գտնում է մուտք գործած օգտատիրոջը և վերադարձնում միայն այն նախագծերը, որտեղ project.company_id-ն համընկնում է օգտատիրոջ ընկերության հետ։ «Վճարված է» կոճակը թաքցնելը բավարար չէ․ վերջնակետն ինքը պետք է մերժի։

Ընդհանուր տերմինների բացատրություն

Տերմին	Նշանակություն
Նույնականացում (AuthN)	Հաստատել, թե ով է մարդը։
Լիազորում (AuthZ)	Որոշել, թե ինչ կարող է անել։
Սեսիա	Հավելվածը հիշում է, որ դուք մուտք եք գործած՝ հարցումների միջև։
Cookie	Փոքր տվյալ, որը բրաուզերը յուրաքանչյուր հարցումով ուղարկում է կայքին։
JWT	JSON Web Token՝ ստորագրված, կոմպակտ թոքեն, որ կրում է այնպիսի տվյալներ, ինչպիսիք են օգտատիրոջ ID-ն և ժամկետը։
Դեր / թույլտվություն	Պիտակներ, ինչպիսիք են `admin`-ը կամ `member`-ը, որոնք որոշում են մուտքը։
MFA / 2FA	Երկրորդ ապացույցի պահանջ, օրինակ՝ նույնականացման հավելվածի կոդ։
SSO	Մեկ մուտք՝ շատ հավելվածների համար (հաճախ ընկերության հաշիվ)։
401 և 403	«Ով ես դու՞» (չնույնականացված) և «Դա չես կարող անել» (չլիազորված)։

Տարածված սխալներ և սխալ պատկերացումներ

Թույլտվությունները ստուգել միայն էջում։ Եթե բրաուզերը կոճակը թաքցնում է, բայց API-ն չի ստուգում, ցանկացած մարդ կարող է ուղղակիորեն կանչել API-ը։
URL-ից ID-ներին վստահելը։ /invoices/1042-ը պետք է ստուգի, որ հաշիվ-ֆակտուրա 1042-ը պատկանում է մուտք գործած օգտատիրոջը։
Սեփական կրիպտոգրաֆիա ստեղծելը։ Օգտագործեք հայտնի գրադարաններ կամ մատակարարներ․ մի թույլ տվեք, որ AI-ը հորինի հեշավորման սխեմա։
Թույլ գաղտնաբառի վերականգնում։ Վերականգնման հղումները պետք է լինեն միանգամյա, արագ ժամկետանց և չհայտնեն, թե արդյոք էլփոստն ունի հաշիվ։
Ձեր մուտքը շփոթել ձեր կառուցիչի մուտքի հետ։ Ձեր հավելվածի օգտատերերը առանձին են ձեր հաշվից այն գործիքում, որով կառուցում եք։
Մուտքի փորձերի սահմանափակում չունենալ։ Առանց դրա հարձակվողները կարող են անվերջ փորձել գաղտնաբառեր։

Ինչ խնդրել ձեր AI կառուցիչից

«Ավելացրու գրանցում և մուտք՝ օգտագործելով [հայտնի գրադարան կամ մատակարար]։ Մի գրիր սեփական գաղտնաբառի հեշավորում։»
«Պահիր գաղտնաբառերը bcrypt-ով կամ Argon2-ով հեշավորված։»
«Սեսիայի համար օգտագործիր HttpOnly, Secure cookie-ներ։»
«Ավելացրու դերեր՝ admin և member։ Թվարկիր յուրաքանչյուր վերջնակետ և ո՞ր դերերը կարող են կանչել այն։»
«Ապահովիր սերվերի վրա, որ օգտատերերը կարող են կարդալ և խմբագրել միայն իրենց գրառումները։ Ապա ցույց տուր, թե ինչպես ես ստուգել։»
«Ավելացրու գաղտնաբառի վերականգնում՝ միանգամյա հղումներով, որոնք ժամկետանց են մեկ ժամից։»
«Սահմանափակիր մուտքի փորձերը։»

Ապա փորձիր ինքդ․ ստեղծիր երկու հաշիվ և փորձիր մուտք գործած մեկի ժամանակ հասնել մյուսի տվյալներին։ Մեր մուտք ավելացնելու ուղեցույցը և անվտանգության ստուգաթերթը ավելի խորն են գնում։

Նույնականացումը Mythex-ում

Mythex-ը չի տրամադրում ներկառուցված նույնականացման արտադրանք ձեր հավելվածի օգտատերերի համար. դուք ընտրում եք մոտեցում՝ էլփոստ և գաղտնաբառ՝ նախագծի տվյալների բազայում, կամ հոստված մատակարարի SDK, և խնդրում եք գործակալին ավելացնել այն։ Մատակարարի բանալիները գնում են նախագծի գաղտնիքների մեջ, ոչ թե չաթում։ Սա առանձին է այն բանից, թե ինչպես եք մուտք գործում Mythex-ում։ Փաստաթղթերի մուտք ավելացնելու հրահանգը ունի մեկնարկային հրահանգ, որ կարող եք հարմարեցնել, իսկ ինչ է API-ն բացատրում է, թե որտեղ են գտնվում սերվերային այդ ստուգումները։

Հարցեր

Ո՞րն է տարբերությունը նույնականացման և լիազորման միջև։

Նույնականացումը ստուգում է, թե ով եք դուք, օրինակ՝ գաղտնաբառը ստուգելով։ Լիազորումը որոշում է, թե ինչ կարող եք անել, երբ արդեն հայտնի եք, օրինակ՝ արդյոք կարող եք տեսնել ադմինի էջը կամ խմբագրել ուրիշի ամրագրումը։ Հավելվածներին անհրաժեշտ են երկուսն էլ։

Ի՞նչ է OAuth-ը։

OAuth 2.0-ը ստանդարտ է, որը թույլ է տալիս հավելվածին սահմանափակ մուտք ստանալ ձեր հաշվին մեկ այլ ծառայությունում՝ առանց ձեր գաղտնաբառը տեսնելու։ «Sign in with Google»-ը օգտագործում է OpenID Connect-ը, որը OAuth 2.0-ի վրա կառուցված ինքնության շերտ է, այնպես որ հավելվածը Google-ից իմանում է, թե ով եք դուք։

Արդյո՞ք իմ հավելվածը պետք է պահի գաղտնաբառեր։

Երբեք ընթեռնելի ձևով։ Եթե օգտագործում եք էլփոստի և գաղտնաբառի մուտք, գաղտնաբառերը պետք է պահվեն աղավ ավելացված հեշերի (salted hash) ձևով՝ գաղտնաբառերի համար նախատեսված դանդաղ ալգորիթմով, օրինակ՝ Argon2 կամ bcrypt։ Շատ հավելվածներ այս խնդրից խուսափում են՝ օգտագործելով հոստինգային նույնականացման մատուցող, սոցիալական մուտք կամ էլփոստային մագիկ հղումներ։

Սեսիաներ, թե թոքեններ․ ո՞րն է պետք օգտագործի իմ հավելվածը։

Երկուսն էլ աշխատում են։ Սեսիան մուտքի վիճակը պահում է սերվերում և բրաուզերին տալիս է պատահական ID cookie-ում, որը հեշտ է չեղարկել։ Թոքենը, օրինակ՝ JWT-ն, իր մեջ է կրում ստորագրված տեղեկություն և հարմար է API-ների ու բջջային հաճախորդների համար, բայց ավարտից առաջ դժվար է չեղարկել։ Սովորական վեբ հավելվածի համար cookie-ի վրա հիմնված սեսիան հուսալի լռելյայն ընտրություն է։