კავშირები (per-user OAuth2)

POST /v1/oauth/token

consent ─▶ code ─▶ POST /v1/oauth/token ─▶ access/refresh token ─▶ vault (encrypted)

**კავშირები** არის ის, თუ როგორ ანიჭებს ცალკეული მომხმარებელი AiHummer-ს წვდომას მესამე მხარის სერვისზე საკუთარი სახელით. ერთი გაზიარებული სერვისის ანგარიშის ნაცვლად, თითოეული ადამიანი ასრულებს სტანდარტულ **OAuth2 authorization-code ნაკადს**, შედეგად მიღებული ტოკენი იბეჭდება დაშიფრულ vault-ში, ხოლო turn-ის დროს რანტაიმი განსაზღვრავს *ამ მომხმარებლის* ტოკენს, როცა tool-ს ის სჭირდება. ეს არის AiHummer-ის სერთიფიკატის მოდელის "პირადი" ნახევარი. უფრო ფართო სურათისთვის — როდის ვამჯობინოთ გაზიარებული სერთიფიკატი და როგორ მუშაობს fallback — იხილეთ [პირადი vs გაზიარებული სერთიფიკატები](/ka/v1.0/access/personal-vs-shared). ## რა არის კავშირი კავშირი აკავშირებს სამ რამეს ერთად: **პროვაიდერს** (OAuth2 აპლიკაცია, რომლის წინააღმდეგაც ანიჭებთ უფლებამოსილებას), **მომხმარებელს** (ადამიანი, რომელმაც დაასრულა თანხმობის ეკრანი) და **vault-ის ჩანაწერს** (სადაც ინახება გაცემული ტოკენი). დადგენის შემდეგ, ნებისმიერ tool-ს, რომელიც მოქმედებს ამ მომხმარებლის სახელით, შეუძლია გამჭვირვალედ გამოიყენოს ტოკენი ისე, რომ ის არასოდეს გამოჩნდეს მოდელის კონტექსტში, ლოგებში ან prompt-ში. კავშირები იმართება admin UI-დან. სიაში ჩანს ყოველი მომხმარებლის დაკავშირებული პროვაიდერები, მათი სტატუსი და როდის განახლდნენ ბოლოს. ## authorization-code ნაკადი კავშირი იქმნება კანონიკური სამფეხა OAuth2 authorization-code grant-ით: 1. მომხმარებელი იწყებს კავშირს პროვაიდერისთვის admin UI-დან. 2. AiHummer გადაამისამართებს ბრაუზერს პროვაიდერის **authorization** endpoint-ზე მოთხოვნილი scope-ებით. 3. მომხმარებელი ამტკიცებს თანხმობის ეკრანს; პროვაიდერი უკან გადაამისამართებს ერთჯერადი **authorization code**-ით. 4. AiHummer ცვლის ამ code-ს **access token**-ზე (და, როცა პროვაიდერი უჭერს მხარს, **refresh token**-ზე) პროვაიდერის token endpoint-ზე. 5. ტოკენი ჩაიწერება vault-ში და კავშირი მონიშნულია აქტიურად. პლატფორმის საკუთარი token endpoint არის: ```http POST /v1/oauth/token ``` ის ასრულებს სერვერის მხარეს code-ის-ტოკენზე გაცვლას ისე, რომ client secret და გაცემული ტოკენი არასოდეს ტოვებენ gateway-ს. > [!NOTE] > authorization-code ნაკადი ყოველთვის მოიცავს ბრაუზერის ნამდვილ თანხმობის ნაბიჯს. > კავშირის შექმნა შეუძლებელია headless რეჟიმში მხოლოდ API გასაღებიდან — მოქმედმა მომხმარებელმა > ერთხელ უნდა დაამტკიცოს scope-ები. ## სად ცხოვრობს ტოკენი გაცემული ტოკენი ინახება AiHummer-ის **დაშიფრულ სერთიფიკატის vault-ში**, არა ღია კონფიგურაციაში. vault იყენებს envelope დაშიფვრას (AES-256-GCM ყოველი მოიჯარისთვის ცალკე data key-ით master key-ის ქვეშ), ხოლო საიდუმლოები არასოდეს კოპირდება მოდელის კონტექსტში, prompt-ებში ან ლოგებში. გაუქმებული ან ვადაგასული კავშირი უბრალოდ ტოვებს არანაირ გამოყენებად საიდუმლოს. ```text consent ─▶ code ─▶ POST /v1/oauth/token ─▶ access/refresh token ─▶ vault (encrypted) ``` ## განსაზღვრება მოქმედი მომხმარებლის მიხედვით კავშირის განმსაზღვრელი თვისებაა ის, რომ ის **განისაზღვრება მოქმედი მომხმარებლის მიხედვით**. როცა აგენტი ასრულებს tool-ს, რომელსაც პროვაიდერი სჭირდება, რანტაიმი ეძებს კავშირს, რომელიც ეკუთვნის მომხმარებელს, ვის სახელითაც მიმდინარეობს turn, და იყენებს *მის* ტოკენს. ამიტომ ორი თანამშრომელი, რომლებიც ერთსა და იმავე აგენტს ესაუბრებიან, მოქმედებენ საკუთარი უფლებამოსილებებით და ხედავენ მხოლოდ იმას, რასაც მათი საკუთარი grant უშვებს. სწორედ ეს ხდის კავშირებს შესაფერისს პირადი, ყოველი მომხმარებლის ინტეგრაციებისთვის: თითოეული ადამიანის წვდომა იზოლირებული, აუდიტირებადი და ინდივიდუალურად გაუქმებადია. ## ხელმისაწვდომი ინტეგრაციები OAuth2 ნაკადის მეშვეობით მომხმარებელს შეუძლია დააკავშიროს საკუთარი ანგარიში ნებისმიერ ჩაშენებულ სერვისს. ეს პირადი ინტეგრაციები ხელმისაწვდომია ყუთიდან გამოსვლისთანავე: | ჯგუფი | სერვისები | |---|---| | **Google** | Gmail, Google Calendar, Google Contacts, Google Tasks, Google Drive, YouTube | | **Microsoft** | Outlook Mail, Outlook Calendar, OneDrive, Microsoft To Do | | **პროდუქტიულობა** | Todoist, Asana, Jira Cloud, ClickUp, GitLab | | **ჯანმრთელობა და ცხოვრების სტილი** | Fitbit, Oura Ring, Spotify, Samsung SmartThings | თითოეული უკავშირდება იმავე authorization-code ნაკადით: მომხმარებელი ასრულებს პროვაიდერის თანხმობის ეკრანს, ტოკენი იბეჭდება vault-ში და ის განისაზღვრება ამ მომხმარებლისთვის ყოველთვის, როცა tool აღწევს სერვისს. ## კავშირების მართვა admin UI-ში admin UI-დან ოპერატორს შეუძლია: - დაინახოს, რომელი პროვაიდერები აქვს დაკავშირებული ყოველ მომხმარებელს და თითოეული ტოკენის სიჯანსაღე. - დაიწყოს ახალი კავშირი (იწყებს თანხმობის ნაკადს არჩეული პროვაიდერისთვის). - გააუქმოს კავშირი, რაც შლის vault-ის ჩანაწერს და თიშავს განსაზღვრებას. კავშირები არსებობს **პერსონალური** (ეკუთვნის კონკრეტულ მომხმარებელს; მას თავად შეუძლია მათი გათიშვა) და **სამუშაო სივრცისთვის გაზიარებული** (მონიშნულია ტეგით «Workspace shared»; მათი პერსონალურად გათიშვა შეუძლებელია). ერთ პროვაიდერზე შესაძლებელია **რამდენიმე ანგარიშის** მიბმა: ღილაკი «+ ანგარიში» ითხოვს წარწერას (label) და ინახავს იმავე პროვაიდერის კიდევ ერთ ანგარიშს — მაგალითად, რამდენიმე Google კალენდარს ან საფოსტო ყუთს. რადგან ფუძემდებლური სერთიფიკატები პირადია, კავშირი ყველაზე ხშირად არის სწორი იარაღი, როცა მოქმედება უნდა მიეწეროს და შეიზღუდოს კონკრეტული ადამიანის უფლებამოსილებით და არა მთელი სამუშაო სივრცის ანგარიშით. ## სად შემდეგ - [პირადი vs გაზიარებული სერთიფიკატები](/ka/v1.0/access/personal-vs-shared) — სრული სფეროს მოდელი და როდის ავირჩიოთ თითოეული. - [BYOK LLM პროვაიდერები](/ka/v1.0/access/byok-providers) — მოიტანეთ საკუთარი მოდელის გასაღებები ყოველი მოიჯარისთვის. - [Marketplace მიმოხილვა და დონეები](/ka/v1.0/marketplace/overview-tiers) — სად ჯდება OAuth-ით მხარდაჭერილი ინტეგრაციები.