რა არის ავთენტიფიკაცია? შესვლა, სესიები და OAuth ახსნილი
ავთენტიფიკაცია არის ის, თუ როგორ ადასტურებს აპი მომხმარებლის ვინაობას — ჩვეულებრივ იმით, რომ ამოწმებს რაღაც, რაც მომხმარებელმა იცის (პაროლი), რაც მას აქვს (კოდი, რომელიც ტელეფონზე ან ელფოსტაზე მოვიდა), ან სანდო სხვა სერვისიდან მიღებულ იდენტობას (მაგალითად „Sign in with Google“). მას შემდეგ, რაც მომხმარებელი ავთენტიფიცირდება, აპი მას სესიით ან ტოკენით იმახსოვრებს, რომ ყოველ გვერდზე თავიდან არ შევიდეს. იმის განსაზღვრა, რა შეუძლია ამ ცნობილ მომხმარებელს, ცალკე ნაბიჯია და ავტორიზაცია ჰქვია.
რატომ არის ეს მნიშვნელოვანი, როცა AI-ით აშენებ
შესვლის დამატება ერთ-ერთი ყველაზე გავრცელებული თხოვნაა, რომელსაც ხალხი AI ბილდერს უგზავნის, და ერთ-ერთი ყველაზე ადვილი რამ, რაც ფარულად არასწორად კეთდება. შესვლის გვერდის გენერირება მარტივია. რთულია ყველაფერი მის გარშემო:
- დაცულად ინახება თუ არა პაროლები?
- ამოწმებს თუ არა ყოველი პირადი გვერდი და ყოველი API endpoint, ვინ ითხოვს მონაცემს?
- შეუძლია თუ არა შესული მომხმარებელს სხვისი მონაცემების ნახვა URL-ში რიცხვის შეცვლით?
- რა ხდება, როცა ვინმე დაივიწყებს პაროლს?
აპს შეიძლება სრულიად უსაფრთხო ეჩვენებოდეს, მიუხედავად იმისა, რომ ყველა ამ კითხვაში ჩავარდება. ამ მექანიზმების გაგება გეხმარება სწორი კითხვების დასმასა და სწორი რამის შემოწმებაში.
ყოველდღიური ანალოგია
წარმოიდგინე სასტუმროში შესვლა.
მიმღებთან ვაჩვენებ პირადობის დამადასტურებელ დოკუმენტს. ეს არის ავთენტიფიკაცია: იმის დამტკიცება, ვინ ხარ. მიმღები შემდეგ გაძლევს საკეტის ბარათს. ეს ბარათი შენი სესიაა: დარჩენის მთელი პერიოდის განმავლობაში დოკუმენტს აღარ აჩვენებ; ბარათს უბრალოდ მიიტან.
ბარათი გიღებს ოთახს, სპორტდარბაზს და ლიფტს შენს სართულზე — მაგრამ არა სხვა სტუმრების ოთახებს და პერსონალის ოთახს. ეს არის ავტორიზაცია: რა წვდომა აქვს შენს იდენტობას. თუ ბარათს დაკარგავ, სასტუმრო მიმღებთან შეუძლია გააუქმოს (სესიის გაუქმება). როცა გასახდელად ხარ, ის აღარ მუშაობს (გასვლა ან ვადის გასვლა).
„Sign in with Google“ ჰგავს იმას, როცა სასტუმრო სანდო პარტნიორისგან წერილს იღებს, სადაც წერია „ეს არის ის ვინც არის“, პირადობის დოკუმენტს თავად არ ამოწმებს.
მთავარი შესვლის მეთოდები
| მეთოდი | როგორ მუშაობს | დადებითი მხარეები | უარყოფითი მხარეები |
|---|---|---|---|
| ელფოსტა + პაროლი | მომხმარებელი ირჩევს პაროლს; აპი ინახავს მის ჰეშს | ნაცნობი, გარე დამოკიდებულების გარეშე | უნდა შეინახო ჰეშები უსაფრთხოდ და პაროლის აღდგენის მართვა |
| მაჯიკ ბმული / ერთჯერადი კოდი | აპი ელფოსტით აგზავნის ბმულს ან კოდს, რომელიც მომხმარებელს შეაბამს | არ არის პაროლები, რომელიც გაჟონა ან დაივიწყება | დამოკიდებულია ელფოსტის მიწოდებაზე; შესვლა უფრო ნელია |
| სოციალური შესვლა (OAuth / OpenID Connect) | მომხმარებელი შედის Google-ით, Apple-ით, GitHub-ით და ა.შ. | მომხმარებლებისთვის სწრაფი; შენ პაროლს არ ინახავ | თითოეულ პროვაიდერთან დაყენება; მომხმარებლები, რომელთაც ამ ანგარიშები არ აქვთ |
| ჰოსტირებული ავთენტიფიკაციის პროვაიდერი | სერვისი, როგორიცაა Clerk, Auth0 ან Supabase Auth, რეგისტრაციას, შესვლასა და აღდგენას ამუშავებს | შენ ნაკლები უსაფრთხოების სამუშაო გაქვს | ყოველთვიური ღირებულება მასშტაბში; კიდევ ერთი დამოკიდებულება |
| მრავალფაქტორული (MFA / 2FA) | პირველის შემდეგ მეორე შემოწმება, მაგალითად ავთენტიკატორის აპის კოდი | ბევრად უფრო რთულია გატეხვა | ცოტა მეტი დაბრკოლება |
როგორ უნდა ინახებოდეს პაროლები
უსაფრთხო აპი არასდროს ინახავს შენს რეალურ პაროლს. მის მაგივრად ინახავს ჰეშს: ერთმიმართულებითი ფუნქციის შედეგს, რომელიც პაროლს ფიქსირებულ სტრიქონად აქცევს. შესვლისას აპი აჰეშებს იმას, რაც ჩაწერე, და შედეგს ინახულ ჰეშთან ადარებს.
ორი დეტალი ამას უსაფრთხოს ხდის:
- მარილი (salt) — შემთხვევითი მნიშვნელობა, რომელიც ყოველ პაროლს ჰეშირებამდე ემატება, ასე რომ ორ ადამიანს ერთი და იგივე პაროლი სხვადასხვა ჰეშს აძლევს და წინასწარ გამოთვლილი ცხრილები უსარგებლო ხდება.
- ნელი ალგორითმი, შექმნილი პაროლებისთვის — მაგალითად Argon2, bcrypt ან scrypt. ზოგადი დანიშნულების ჰეშები, როგორიცაა MD5 ან SHA-256, მარტო ძალიან სწრაფია; შემტევებს მილიარდობით ცდის გაკეთება შეუძლიათ.
ჰეშირება არ არის იგივე, რაც დაშიფვრა. დაშიფრული მონაცემი შეიძლება გასაღებით გაშიფრული იყოს; პაროლის ჰეში კი შექმნილია იმისთვის, რომ საერთოდ არ შეიცვალოს უკან.
სესიები vs ტოკენები
შესვლის შემდეგ აპს ყოველ მოთხოვნაზე უნდა გიცნოს. არსებობს ორი გავრცელებული მიდგომა.
| სესია (cookie) | ტოკენი (მაგ. JWT) | |
|---|---|---|
| რას ინახავს ბრაუზერი | შემთხვევით სესიის ID-ს cookie-ში | ხელმოწერილ ტოკენს, რომელიც შეიცავს მომხმარებლის ინფორმაციას და ვადას |
| სად ცხოვრობს შესვლის მდგომარეობა | სერვერზე, მონაცემთა ბაზაში ან საცავში | თავად ტოკენში |
| ყველგან გასვლა | მარტივი: სერვერზე სესიას შლი | უფრო რთული: ტოკენი ვადამდე ძალაშია, თუ არ გაქვს შავი სია |
| ტიპური გამოყენება | ტრადიციული ვებ აპები | API-ები, მობილური აპები, სერვისები, რომლებიც ერთმანეთს ესაუბრებიან |
cookie-ებისთვის სამი პარამეტრი მნიშვნელოვანია: HttpOnly (გვერდზე JavaScript cookie-ს ვერ წაიკითხავს), Secure (იგზავნება მხოლოდ HTTPS-ზე) და SameSite (ზღუდავს მის გაგზავნას სხვა საიტებიდან მოთხოვნებზე). ტოკენების ბრაუზერის localStorage-ში შენახვა გავრცელებულია, მაგრამ მათ ნებისმიერი სკრიპტი, რომელიც გვერდზე მუშაობს, ხელმისაწვდომს ხდის.
OAuth და „Sign in with Google“
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-ს; secret სერვერზე რჩება.
სამუშაო მაგალითი: შესვლა კლიენტის პორტალისთვის
ვთქვათ, აშენებ პორტალს, სადაც დიზაინის სააგენტოს კლიენტები თავიანთ პროექტებსა და ინვოისებს ხედავენ.
- ავთენტიფიკაცია: კლიენტები შედიან ელფოსტითა და მაჯიკ ბმულით, ასე რომ პაროლები არ არსებობს სამართავად. სააგენტოს თანამშრომლები შედიან Google Workspace ანგარიშებით.
- როლები: თითოეულ მომხმარებელს აქვს როლი —
clientანstaff. - ავტორიზაციის წესები:
| მოქმედება | კლიენტი | თანამშრომელი |
|---|---|---|
| საკუთარი კომპანიის პროექტების ნახვა | დიახ | დიახ |
| სხვა კომპანიების პროექტების ნახვა | არა | დიახ |
| ფაილის ატვირთვა პროექტში | მხოლოდ საკუთარ პროექტებში | დიახ |
| ინვოისის გადახდილად მონიშვნა | არა | დიახ |
- სად ხორციელდება: სერვერზე, ყოველ მოთხოვნაზე. სერვერი პოულობს შესულ მომხმარებელს და აბრუნებს მხოლოდ იმ პროექტებს, სადაც
project.company_idემთხვევა მომხმარებლის კომპანიას. „მონიშნულია გადახდილად“ ღილაკის დამალვა საკმარისი არ არის — endpoint თავად უნდა უარყოფდეს მოთხოვნას.
საერთო ტერმინები
| ტერმინი | მნიშვნელობა |
|---|---|
| ავთენტიფიკაცია (AuthN) | იმის დადასტურება, თუ ვინ არის ვინმე. |
| ავტორიზაცია (AuthZ) | იმის გადაწყვეტა, რა შეუძლია მას. |
| სესია (Session) | აპი იმახსოვრებს, რომ შესული ხარ მოთხოვნებს შორის. |
| Cookie | პატარა მონაცემი, რომელსაც ბრაუზერი თითოეულ მოთხოვნაზე საიტს უბრუნებს. |
| JWT | JSON Web Token: ხელმოწერილი, კომპაქტური ტოკენი, რომელიც ატარებს მონაცემებს, როგორიცაა მომხმარებლის ID და ვადა. |
| როლი / უფლება (Role / permission) | ეტიკეტები, როგორიცაა admin ან member, რომლებიც წვდომას განსაზღვრავს. |
| MFA / 2FA | მეორე დადასტურების მოთხოვნა, მაგალითად ავთენტიკატორის აპიდან კოდი. |
| SSO | Single sign-on: ერთი შესვლა (ხშირად კომპანიის ანგარიშით) ბევრ აპში. |
| 401 vs 403 | „ვინ ხარ?“ (არაავთენტიფიცირებული) vs „ამის უფლება არ გაქვს“ (არაავტორიზებული). |
გავრცელებული შეცდომები და მცდარი წარმოდგენები
- უფლებების შემოწმება მხოლოდ გვერდზე. თუ ბრაუზერი ღილაკს მალავს, მაგრამ API არ ამოწმებს, ნებისმიერს შეუძლია API-ის პირდაპირ გამოძახება.
- URL-ის ID-ების ნდობა.
/invoices/1042უნდა ამოწმებდეს, რომ ინვოისი 1042 შესული მომხმარებლის ეკუთვნის. - საკუთარი კრიპტოგრაფიის შექმნა. გამოიყენე კარგად ცნობილი ბიბლიოთეკები ან პროვაიდერები; AI-ს არ მისცე საშუალება, თავად გამოიგონოს ჰეშირების სქემა.
- სუსტი პაროლის აღდგენა. აღდგენის ბმულები უნდა იყოს ერთჯერადი, სწრაფად ვადაგასული და არ უნდა ამჟღავნებდეს, აქვს თუ არა ელფოსტას ანგარიში.
- შენი შესვლის აღრევა ბილდერის შესვლასთან. შენი აპის მომხმარებლები განცალკევებულია იმ ანგარიშისგან, რომლითაც ინსტრუმენტში აშენებ.
- შესვლაზე სიხშირის შეზღუდვის (rate limiting) არ არსებობა. მის გარეშე შემტევებს შეუძლიათ უსასრულოდ სცადონ პაროლები.
რა მოსთხოვო შენს AI ბილდერს
- „დაამატე რეგისტრაცია და შესვლა [კარგად ცნობილი ბიბლიოთეკით ან პროვაიდერით]. არ დაწერო საკუთარი პაროლის ჰეშირება.“
- „შეინახე პაროლები bcrypt-ით ან Argon2-ით ჰეშირებული.“
- „გამოიყენე HttpOnly, Secure cookie-ები სესიისთვის.“
- „დაამატე როლები: admin და member. ჩამოთვალე ყველა endpoint და რომელ როლებს შეუძლიათ მისი გამოძახება.“
- „სერვერზე უზრუნველყავი, რომ მომხმარებლებს შეეძლებათ მხოლოდ საკუთარი ჩანაწერების წაკითხვა და რედაქტირება. შემდეგ აჩვენე, როგორ შეამოწმე.“
- „დაამატე პაროლის აღდგენა ერთჯერადი ბმულებით, რომლებიც ერთი საათის შემდეგ ვადაგადის.“
- „შეზღუდე შესვლის მცდელობების სიხშირე.“
შემდეგ თავად გამოსცადე: შექმენი ორი ანგარიში და სცადე ერთის მონაცემებზე წვდომა მეორით შესვლისას. გზამკვლევი, როგორ დავამატოთ შესვლა აპში და უსაფრთხოების სია AI-ით აშენებული აპებისთვის უფრო შორს მიდის.
ავთენტიფიკაცია Mythex-ში
Mythex არ გთავაზობს ჩაშენებულ ავთენტიფიკაციის პროდუქტს შენი აპის მომხმარებლებისთვის; შენ ირჩევ მიდგომას — ელფოსტა და პაროლი, რომელიც შენი პროექტის მონაცემთა ბაზაში ინახება, ან ჰოსტირებული პროვაიდერის SDK — და აგენტს სთხოვ მის დამატებას. პროვაიდერის გასაღებები პროექტის საიდუმლოებში შედის, არა ჩატში. ეს განსხვავდება იმისგან, თუ როგორ შედიხარ თავად Mythex-ში. დოკუმენტაციის რეცეპტს შესვლის დამატება აპში აქვს საწყისი მოთხოვნა, რომლის მორგებაც შეგიძლია, ხოლო რა არის API განმარტავს, სად ცხოვრობენ ეს სერვერული შემოწმებები.
კითხვები
რა განსხვავებაა ავთენტიფიკაციასა და ავტორიზაციას შორის?
ავთენტიფიკაცია ამოწმებს, ვინ ხარ — მაგალითად, პაროლის შემოწმებით. ავტორიზაცია კი გადაწყვეტს, რა შეგიძლია გააკეთო მას შემდეგ, რაც ცნობილი ხარ, მაგალითად, შეგიძლია თუ არა ადმინისტრატორის გვერდის ნახვა ან სხვისი დაჯავშნის რედაქტირება. აპებს ორივე სჭირდებათ.
რა არის OAuth?
OAuth 2.0 არის სტანდარტი, რომელიც აპს აძლევს შეზღუდულ წვდომას შენს ანგარიშზე სხვა სერვისზე, ისე რომ პაროლს არ ხედავს. „Sign in with Google“ იყენებს OpenID Connect-ს, რომელიც OAuth 2.0-ის თავზე აშენებული იდენტობის ფენაა, ამიტომ აპი Google-დან იგებს, ვინ ხარ.
უნდა ინახავდეს აპი პაროლებს?
არასდროს წაკითხვად ფორმაში. თუ იყენებ ელფოსტა-და-პაროლის შესვლას, პაროლები უნდა ინახებოდეს დამარილებული ჰეშების სახით, პაროლებისთვის განკუთვნილი ნელი ალგორითმით, მაგალითად Argon2 ან bcrypt. ბევრი აპი ამ საკითხს ჰოსტირებული ავთენტიფიკაციის პროვაიდერით, სოციალური შესვლით ან ელფოსტით მიღებული ერთჯერადი ბმულებით თავიდან აცილებს.
რომელი უნდა გამოიყენოს ჩემმა აპმა — სესიები თუ ტოკენები?
ორივე მუშაობს. სესია სერვერზე ინახავს შესვლის მდგომარეობას და ბრაუზერს cookie-ში შემთხვევით ID-ს აძლევს, რაც მარტივად გასაუქმებელია. ტოკენი, მაგალითად JWT, თავად ატარებს ხელმოწერილ ინფორმაციას, რაც API-ებსა და მობილურ კლიენტებს შეეფერება, მაგრამ ვადის გასვლამდე გაუქმება უფრო რთულია. ტიპური ვებ აპისთვის cookie-ზე დაფუძნებული სესიები საიმედო ნაგულისხმევი არჩევანია.