Ինչ է authorization-ը իրականում՝ պարզ բացատրությամբ

Շատ սկսնակներ authorization բառը լսելիս այն շփոթում են authentication-ի հետ։

Այս երկու գաղափարները իրար շատ մոտ են, բայց լուծում են տարբեր խնդիրներ։ Authentication-ը պատասխանում է հարցին՝ «ո՞վ ես դու»։ Authorization-ը պատասխանում է հարցին՝ «ի՞նչ իրավունք ունես անել»։

Այս տարբերությունը հեշտ է հասկանալ իրական օրինակով։ Պատկերացրեք, որ մտնում եք ընկերության գրասենյակ և մուտքի մոտ ցույց եք տալիս ձեր անցաթուղթը։ Անվտանգության աշխատակիցը ստուգում է, որ անցաթուղթը իսկապես ձերն է։ Դա authentication է։ Բայց հետո՝ կարո՞ղ եք մտնել ֆինանսների սենյակ, կարո՞ղ եք բացել սերվերայինը, կարո՞ղ եք հաստատել վճարումները, կարո՞ղ եք տեսնել HR տվյալները։ Այս որոշումները արդեն authorization-ի մասին են։

Authorization-ը թույլտվության մասին է

Authorization-ը հասկանալու ամենապարզ ձևը սա է․ համակարգն արդեն գիտի՝ ով եք դուք, և հիմա որոշում է՝ ինչին եք իրավունք ստանում հասնել կամ ինչ կարող եք փոխել։ Այստեղ խոսքը այլևս ինքնության մասին չէ։ Խոսքը լիազորությունների սահմանների մասին է։

Սա կարևոր է, որովհետև շատ համակարգեր ունեն տարբեր տեսակի տվյալներ և գործողություններ։ Ամեն օգտատեր չպետք է տեսնի ամեն ինչ։ Ամեն աշխատակից չպետք է հասնի ադմին գործիքների։ Ամեն հաճախորդ չպետք է կարողանա փոխել վճարային կարգավորումները։ Առանց authorization-ի բոլոր նույնականացված օգտատերերը կարող են չափազանց շատ ուժ ստանալ։

Պարզ օրինակ

Պատկերացրեք թիմի կառավարման հավելված, որտեղ կան երեք օգտատեր՝ սովորական աշխատակից, մենեջեր և ադմինիստրատոր։ Երեքն էլ կարող են մուտք գործել իրենց վավեր հաշիվներով։ Այսինքն՝ երեքն էլ անցնում են authentication-ը։ Բայց համակարգ մտնելուց հետո նրանք չպետք է նույն բաները տեսնեն։

• աշխատակիցը կարող է տեսնել իրեն կցված առաջադրանքները
• մենեջերը կարող է փոխել թիմի աշխատանքային հոսքերը
• ադմինիստրատորը կարող է ստեղծել օգտատերեր և փոխել համակարգի կարգավորումները

Հավելվածը authorization որոշումներ է ընդունում ամեն անգամ, երբ որոշում է՝ ով ինչ կարող է տեսնել, փոխել, ջնջել կամ կառավարել։

Ինչու authentication-ը միայնակ բավարար չէ

Սկսնակների տարածված սխալ պատկերացումն այն է, որ եթե օգտատերը հաջողությամբ մուտք է գործել, ապա հիմնական անվտանգության խնդիրը լուծված է։ Այդպես չէ։ Իմանալը, որ մարդը իրական օգտատեր է, միայն առաջին քայլն է։ Համակարգը նաև պետք է որոշի՝ արդյոք տվյալ օգտատերը պետք է ունենա կոնկրետ գործողություն կատարելու իրավունք։

Օրինակ՝ եթե ցանկացած մուտք գործած օգտատեր կարողանար ջնջել բոլոր գրառումները, տեսնել մասնավոր հաշվետվությունները կամ փոխել այլ օգտատիրոջ գաղտնաբառը, այդ համակարգը դեռ վտանգավոր կդիտվեր, նույնիսկ եթե login-ը լավ պաշտպանված լիներ։

Authorization-ը ամենուր է ծրագրային աշխարհում

Երբ հասկանում եք այս գաղափարը, սկսում եք authorization-ը տեսնել բազմաթիվ առօրյա պրոդուկտներում՝

• որոշ օգտատերեր կարող են միայն կարդալ տվյալները, մյուսները՝ խմբագրել
• որոշ թիմակիցներ կարող են հրավիրել նոր օգտատերերի, մյուսները՝ ոչ
• որոշ հաշիվներ կարող են հասնել premium հնարավորություններին, մյուսները մնում են free փաթեթում
• որոշ մարդիկ կարող են տեսնել ներքին dashboard-ները, մյուսները՝ միայն public էջերը
• որոշ API key-եր կարող են միայն կարդալ, մյուսները՝ նաև գրել կամ ջնջել

Այս ամենը օրինակներ են այն բանի, թե ինչպես է ծրագիրը որոշում ոչ թե ով եք դուք, այլ ինչին եք իրավասու։

Ինչպես են համակարգերը սովորաբար կազմակերպում authorization-ը

Տարբեր համակարգեր authorization-ը տարբեր ձևերով են իրականացնում, բայց հիմնական գաղափարը նույնն է մնում։ Համակարգը կարող է նշանակել դերեր, օրինակ՝ user, editor, manager, admin։ Այն կարող է սահմանել թույլտվություններ, օրինակ՝ read, write, update, delete։ Այն կարող է նաև կանոններ կիրառել սեփականության, բաժանորդագրության փաթեթի, բաժնի կամ ռեսուրսի տեսակի հիման վրա։

Օրինակ՝ փաստաթղթերի հավելվածը կարող է թույլ տալ ձեզ խմբագրել ձեր ֆայլը, բայց ոչ ուրիշինը։ Billing համակարգը կարող է support թիմին թույլ տալ տեսնել հաշիվները, բայց միայն finance թիմին թույլ տալ վերադարձ կատարել։ Սրանք authorization կանոններ են գործողության մեջ։

Ինչու իրական համակարգերում authorization-ը բարդանում է

Authorization-ը պարզ է թվում, երբ համակարգը փոքր է։ Բայց երբ ծրագիրը մեծանում է, թույլտվությունների տրամաբանությունը զգալիորեն բարդանում է։ Դերերը կարող են իրար խառնվել։ Բացառություններ են առաջանում։ Ժամանակավոր հասանելիություն կարող է պետք գալ։ Մի թիմին կարող է պետք լինել միայն read-only հասանելիություն, իսկ մյուսին՝ edit հասանելիություն միայն մեկ բաժնում։ Այդ պատճառով թույլտվությունների դիզայնը լուրջ պրոդուկտների ճարտարապետության կարևոր մաս է դառնում։

Թույլ authorization մոդելը հաճախ ստեղծում է թաքնված ռիսկեր։ Խառն authorization մոդելը ստեղծում է շփոթություն, bug-եր և support խնդիրներ։

Authorization-ը նաև պրոդուկտի դիզայնի որոշում է

Շատերը կարծում են, որ authorization-ը միայն backend անվտանգության թեմա է։ Բայց այն նաև խորապես կապված է պրոդուկտի դիզայնի հետ։ Ո՞վ պետք է տեսնի որ կոճակը։ Ո՞ր menu item-երը պետք է թաքցվեն։ Ո՞ր գործողությունները պետք է անջատվեն։ Ո՞ր փաթեթն է բացում որ հնարավորությունները։ Սրանք user experience հարցեր են, որոնք կառուցված են authorization տրամաբանության վրա։

Այլ կերպ ասած՝ authorization-ը ձևավորում է ոչ միայն անվտանգությունը, այլ նաև հենց պրոդուկտի կառուցվածքը։

Ինչու սա կարևոր է նույնիսկ եթե backend ծրագրավորող չեք

Այս գաղափարից օգտվելու համար պետք չէ access-control կոդ գրել։ Հիմնադիրները, product manager-ները, դիզայներները, անալիտիկները և support թիմերը բոլորը առնչվում են թույլտվությունների հարցերի հետ։ Երբ authorization-ը հստակ եք հասկանում, շատ պրոդուկտային վարքեր ավելի պարզ են դառնում՝ ինչու մեկ օգտատեր ֆիչերը տեսնում է, իսկ մյուսը՝ ոչ, ինչու ներքին գործիքներին պետք են role-եր, կամ ինչու enterprise պրոդուկտները այդքան ժամանակ են ծախսում permissions-ի վրա։

Դուք սկսում եք authorization-ը տեսնել որպես այն հիմնական մեխանիզմներից մեկը, որով ծրագրերը կազմակերպում են ուժը և հասանելիությունը։

Եզրակացություն

Authorization-ը որոշում է, թե ինչ է թույլատրված անել արդեն նույնականացված օգտատիրոջը։ Authentication-ը նախ ապացուցում է ինքնությունը։ Authorization-ը հետո որոշում է լիազորությունները։ Երբ այս տարբերությունը հասկանում եք, շատ ծրագրային համակարգեր շատ ավելի հասկանալի են դառնում։