რა არის OAuth? «Sign in with Google» და დელეგირებული წვდომა ახსნილი

OAuth არის ღია სტანდარტი, რომელიც მომხმარებელს საშუალებას აძლევს, ერთ აპლიკაციას შეზღუდული წვდომა მისცეს თავის ანგარიშზე სხვა სერვისში, პაროლის გადაცემის გარეშე. როცა დააჭერთ «Connect Google Calendar»-ს და ხედავთ ეკრანს, სადაც წერია «ნებას ვრთავთ ამ აპლიკაციას, ნახოს თქვენი ღონისძიებები?», ეს OAuth-ია. აპლიკაცია იღებს token-ს იმისთვის, რაც დაადასტურეთ, და ამ წვდომას ნებისმიერ დროს გააუქმებთ. იგივე მექანიზმი, დამატებული ფენით, სახელად OpenID Connect, უზრუნველყოფს «Sign in with Google»-ისა და მსგავსი ღილაკების მუშაობას.

რატომ არის OAuth მნიშვნელოვანი AI-ით აგებისას

OAuth აპლიკაციის აგებისას ორ გავრცელებულ სიტუაციაში ჩნდება:

1. სოციალური შესვლა. გსურთ, რომ მომხმარებლებმა შევიდნენ «Sign in with Google»-ით (ან Apple-ით, Microsoft-ით, GitHub-ით) ახალი პაროლის შექმნის ნაცვლად. იხილეთ როგორ დავამატოთ შესვლა აპლიკაციაში.
2. დაკავშირება მომხმარებლების ანგარიშებთან სხვა სერვისებზე. აპლიკაციას სჭირდება მომხმარებლის კალენდარის წაკითხვა, მისი სოციალური ანგარიშიდან პოსტინგი, ფაილების ჩამოტანა მისი cloud დისკიდან ან საბუღალტრო მონაცემების სინქრონიზაცია.

ორივე შემთხვევაში AI ამგებს კოდის დაწერა შეუძლია, მაგრამ ზოგი ნაბიჯი მხოლოდ თქვენ შეგიძლიათ: პროვაიდერთან დეველოპერული აპლიკაციის შექმნა, client ID-ისა და client secret-ის მიღება, callback URL-ების რეგისტრაცია და, ზოგიერთი ნებართვისთვის, პროვაიდერის შემოწმებაში გავლა. OAuth-ის მუშაობის ცოდნა ამ ნაბიჯებსა და მათ მიერ წარმოქმნილ შეცდომებს ბევრად ნაკლებად იდუმალს ხდის. შესვლის უფრო ფართო სურათისთვის იხილეთ რა არის ავთენტიფიკაცია.

ყოველდღიური ანალოგია

იფიქრეთ სასტუმროს ბარათზე. ჩექინის დროს მიმღებელი ადასტურებს, ვინ ხართ, შემდეგ გაძლევთ ბარათს, რომელიც ხსნის თქვენს ოთახსა და ფიტნეს დარბაზს — არა სხვა ოთახებს, არა პერსონალის ზონებს — და გაჩერდება მოქმედებას ჩექაუთზე. ბარათი არ შეიცავს თქვენს პასპორტს. თუ დაკარგავთ, მიმღებლობა აუქმებს მას და ახალს გცემთ.

• მიმღებლობა არის ავტორიზაციის სერვერი (Google-ის შესვლის გვერდი).
• თქვენი პირადობის შემოწმება არის Google-ში თქვენი შესვლა.
• საკეტის ბარათი არის access token.
• «მხოლოდ ოთახი და დარბაზი» არის scope-ები, რომლებსაც დაადასტურეთ.
• ჩექაუთი არის token-ის ვადის გასვლა ან წვდომის გაუქმება თქვენ მიერ.

აპლიკაცია, რომელსაც იყენებთ, თქვენს Google პაროლს არასდროს ხედავს, მხოლოდ ბარათს.

როგორ მუშაობს OAuth, ნაბიჯ-ნაბიჯ

ვებ-აპლიკაციებისთვის ყველაზე გავრცელებული ნაკადია authorization code flow. აი, რა ხდება, როცა მომხმარებელი აკავშირებს Google Calendar-ს გრაფიკის აპლიკაციასთან:

1. დაჭერა. მომხმარებელი აჭერს «Connect Google Calendar»-ს.
2. გადამისამართება პროვაიდერთან. აპლიკაცია ბრაუზერს Google-თან აგზავნის თავისი client ID-ით, იმ scope-ებით, რომლებიც სურს (კალენდარის ღონისძიებების წაკითხვა), და redirect URI-ით, სადაც Google მომხმარებელს დააბრუნებს.
3. შესვლა და თანხმობა. მომხმარებელი შედის Google-ში (თუ უკვე არ არის) და ხედავს თანხმობის ეკრანს, სადაც ჩამოთვლილია, რაც აპლიკაციას სჭირდება. აჭერს Allow-ს.
4. დაბრუნება კოდით. Google ბრაუზერს აპლიკაციის redirect URI-ზე აბრუნებს მოკლევადიანი, ერთჯერადი authorization code-ით.
5. გაცვლა სერვერზე. აპლიკაციის სერვერი ამ კოდს, client secret-თან ერთად, პირდაპირ Google-ს უგზავნის და იღებს access token-ს (და ხშირად refresh token-ს).
6. API-ის გამოყენება. სერვერი იძახებს Google Calendar API-ს access token-ით და იღებს მომხმარებლის ღონისძიებებს.

მე-4 ნაბიჯის callback ასე გამოიყურება:

https://yourapp.com/auth/google/callback?code=4/0Adeu5B...&state=x7Kq9

ხოლო მე-5 ნაბიჯის token-ის პასუხი JSON-ია:

{
  "access_token": "ya29.a0Af...",
  "expires_in": 3599,
  "refresh_token": "1//0gL...",
  "scope": "https://www.googleapis.com/auth/calendar.readonly",
  "token_type": "Bearer"
}

მნიშვნელოვანი დიზაინის წერტილი: token-ის გაცვლა სერვერიდან სერვერზე ხდება, ამიტომ client secret და token-ები ბრაუზერში არასდროს გადის.

OAuth vs OpenID Connect vs თქვენი საკუთარი შესვლა

ბევრი აპლიკაცია მათ აერთიანებს: ელფოსტა-პაროლით შესვლა, პლუს «Sign in with Google» OIDC-ით, პლუს ცალკე OAuth კავშირები სხვა სერვისებთან.

ძირითადი ტერმინები

გავრცელებული მცდარი წარმოდგენები

• «OAuth შესვლის სისტემაა.» ჩვეულებრივი OAuth წვდომას ანიჭებს; identity-ზე OpenID Connect ზრუნავს. შიშველი access token-ის გამოყენება იმის დასამტკიცებლად, თუ ვინ არის ადამიანი, რეალურ უსაფრთხოების შეცდომებს იწვევდა.
• «აპლიკაციას ჩემი პაროლი ეძლევა.» არასდროს. სწორედ ამისთვისაა ეს სისტემა.
• «მეტი scope-ის მოთხოვნა უვნებელია.» მომხმარებლები ფრთხილობენ ფართო მოთხოვნებზე, ხოლო ისეთი პროვაიდერები, როგორიცაა Google, შეიძლება მოითხოვდნენ აპლიკაციის შემოწმებას მგრძნობიარე ან შეზღუდული scope-ებისთვის. მოითხოვეთ მხოლოდ საჭიროები.
• «Client secret შეიძლება frontend-ში ჩაიდოს.» ბრაუზერის კოდში ყველაფერი საჯაროა. შეინახეთ სერვერულ საიდუმლოებებში.
• «მუშაობს ტესტირებაში, ე.ი. იმუშავებს პროდაქშენშიც.» პროვაიდერები ხშირად ზღუდავენ შემოწმებულ აპლიკაციებს — მაგალითად, მხოლოდ ჩამოთვლილ სატესტო მომხმარებლებს — და ცოცხალი დომენის redirect URI ცალკე უნდა დარეგისტრირდეს.
• «Token-ები სამუდამოდ არსებობს.» Access token-ები სწრაფად იწურება, და მომხმარებლებს წვდომის გაუქმება შეუძლიათ. აპლიკაციამ ორივე უნდა გაართვას თავი.

რა ვკითხოთ თქვენს AI ამგებს

• «დაამატე «Sign in with Google» OpenID Connect-ით კარგად მოვლილი ავთენტიფიკაციის ბიბლიოთეკით — OAuth ნაკადი ხელით ნუ დაწერ.»
• «გამოიყენე authorization code flow PKCE-ით და შეამოწმე state პარამეტრი.»
• «client ID და client secret სერვერზე გარემოს ცვლადებიდან წაიკითხე.»
• «მოითხოვე მხოლოდ საჭირო scope-ები: კალენდარის მხოლოდ წაკითხვა.»
• «მითხარი, რა redirect URL-ები უნდა დარეგისტრირდეს პროვაიდერის კონსოლში: preview-სთვის, გამოქვეყნებული URL-ისთვის და ჩემი მორგებული დომენისთვის.»
• «refresh token-ები შიფრული შეინახე მონაცემთა ბაზაში და ვადაგასული ან გაუქმებული token-ები მოამუშავე მომხმარებლისთვის ხელახლა დაკავშირების თხოვნით.»
• «მომხმარებლებს მიეცით საშუალება, გათიშონ ინტეგრაცია თავიანთი პარამეტრების გვერდიდან.»

OAuth და Mythex

Mythex-ს არ აქვს ჩაშენებული ბოლო მომხმარებლის შესვლა თქვენ მიერ აგებული აპლიკაციებისთვის; მისი დოკუმენტაცია აღწერს მიდგომას «შენი საკუთარი მოიტანე»: თქვენ ირჩევთ ავთენტიფიკაციის ბიბლიოთეკას ან ჰოსტირებულ პროვაიდერს, მის გასაღებებს ინახავთ როგორც პროექტის საიდუმლოებებს, და აგენტი წერს კოდს. ამისთვის ავთენტიფიკაციის დამატების რეცეპტში არის საწყისი მოთხოვნა. OAuth თავად Mythex-შიც შეგხვდებათ: Google-ით რეგისტრაცია შეგიძლიათ, GitHub-ის დაკავშირება რეპოზიტორიის სინქრონიზაციისთვის GitHub OAuth-ს იყენებს, ხოლო AI კლიენტები, რომლებიც Mythex-ს MCP-ით უკავშირდებიან, OAuth თანხმობის გვერდზე გადიან. მეტი იხილეთ რა არის ავთენტიფიკაცია და რა არის ორფაქტორიანი ავთენტიფიკაცია.

კითხვები