Bağlantılar (hər istifadəçi üzrə OAuth2)

POST /v1/oauth/token

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

**Bağlantılar** fərdi istifadəçinin AiHummer-ə üçüncü tərəf xidmətinə öz adından giriş icazəsi verməsinin yoludur. Tək bir paylaşılan xidmət hesabı əvəzinə, hər şəxs standart **OAuth2 authorization-code axını** işə salır, alınan token şifrələnmiş seyfdə möhürlənir, və növbə zamanı runtime bir alətin ehtiyacı olduqda *həmin istifadəçinin* token-ini həll edir. Bu, AiHummer-in kimlik məlumatları modelinin "şəxsi" yarısıdır. Daha geniş mənzərə üçün — nə zaman paylaşılan kimlik məlumatına üstünlük verilməli və geri-çəkilmə necə işləyir — bax [Şəxsi vs paylaşılan kimlik məlumatları](/en/v1.0/access/personal-vs-shared). ## Bağlantı nədir Bağlantı üç şeyi birləşdirir: bir **provayder** (avtorizasiya etdiyiniz OAuth2 tətbiqi), bir **istifadəçi** (razılıq ekranını tamamlayan şəxs), və bir **seyf qeydi** (verilmiş token-in saxlandığı yer). Bir dəfə qurulduqdan sonra, həmin istifadəçinin adından fəaliyyət göstərən istənilən alət token-i şəffaf şəkildə istifadə edə bilər və o, heç vaxt model kontekstində, loglarda və ya prompt-da görünmür. Bağlantılar admin UI-dən idarə olunur. Siyahı hər istifadəçinin qoşulmuş provayderlərini, onların statusunu və nə vaxt sonuncu dəfə yeniləndiyini göstərir. ## Authorization-code axını Bağlantı kanonik üç-mərhələli OAuth2 authorization-code grant ilə yaradılır: 1. İstifadəçi admin UI-dən bir provayder üçün bağlantını başladır. 2. AiHummer brauzeri provayderin **authorization** endpoint-inə tələb olunan scope-larla yönləndirir. 3. İstifadəçi razılıq ekranını təsdiqləyir; provayder birdəfəlik **authorization code** ilə geri yönləndirir. 4. AiHummer həmin kodu provayderin token endpoint-ində **access token**-ə (və provayder dəstəklədikdə **refresh token**-ə) dəyişir. 5. Token seyfə yazılır və Bağlantı aktiv kimi işarələnir. Platformanın öz token endpoint-i belədir: ```http POST /v1/oauth/token ``` O, server tərəfli kod-üçün-token dəyişməsini həyata keçirir ki, müştəri secret-i və verilmiş token heç vaxt gateway-i tərk etməsin. > [!NOTE] > Authorization-code axını həmişə real brauzer razılıq addımını əhatə edir. Bağlantı > təkcə bir API açarından baş-sız yaradıla bilməz — fəaliyyət göstərən istifadəçi > scope-ları bir dəfə təsdiqləməlidir. ## Token harada yaşayır Verilmiş token açıq konfiqurasiyada deyil, AiHummer-in **şifrələnmiş kimlik məlumatı seyfində** saxlanılır. Seyf zərf şifrələməsindən istifadə edir (master açar altında hər tenant üzrə data açarı ilə AES-256-GCM), və gizli açarlar heç vaxt model kontekstinə, prompt-lara və ya loglara kopyalanmır. Ləğv edilmiş və ya müddəti bitmiş Bağlantı sadəcə arxasında istifadəyə yararlı heç bir gizli açar buraxmır. ```text consent ─▶ code ─▶ POST /v1/oauth/token ─▶ access/refresh token ─▶ vault (encrypted) ``` ## Fəaliyyət göstərən istifadəçi üzrə həll edilir Bağlantının müəyyənedici xüsusiyyəti odur ki, o, **fəaliyyət göstərən istifadəçi üzrə həll edilir**. Bir agent provayderə ehtiyacı olan alət işlədərkən, runtime növbənin adından işlədiyi istifadəçiyə aid Bağlantını axtarır və *onların* token-ini istifadə edir. Beləliklə, eyni agentlə danışan iki işçi öz avtorizasiyaları ilə fəaliyyət göstərir və yalnız öz icazələrinin imkan verdiyini görür. Bu, Bağlantıları şəxsi, hər istifadəçi üzrə inteqrasiyalar üçün uyğun edən şeydir: hər şəxsin girişi izolyasiya edilmiş, audit edilə bilən və fərdi şəkildə ləğv edilə biləndir. ## Mövcud inteqrasiyalar OAuth2 axını vasitəsilə istifadəçi öz hesabını göndərilən xidmətlərdən hər hansı birinə qoşa bilər. Bu şəxsi inteqrasiyalar qutudan çıxan kimi mövcuddur: | Qrup | Xidmətlər | |---|---| | **Google** | Gmail, Google Calendar, Google Contacts, Google Tasks, Google Drive, YouTube | | **Microsoft** | Outlook Mail, Outlook Calendar, OneDrive, Microsoft To Do | | **Məhsuldarlıq** | Todoist, Asana, Jira Cloud, ClickUp, GitLab | | **Sağlamlıq və həyat tərzi** | Fitbit, Oura Ring, Spotify, Samsung SmartThings | Onların hər biri eyni authorization-code axını ilə qoşulur: istifadəçi provayderin razılıq ekranını tamamlayır, token seyfdə möhürlənir, və bir alət xidmətə çatdıqda həmin istifadəçi üçün həll edilir. ## Admin UI-də bağlantıları idarə etmək Admin UI-dən operator aşağıdakıları edə bilər: - Hər istifadəçinin hansı provayderləri qoşduğunu və hər token-in sağlamlığını görmək. - Yeni bağlantı başlatmaq (seçilmiş provayder üçün razılıq axınını işə salmaq). - Bağlantını ləğv etmək, bu da seyf qeydini silir və həllini söndürür. Bağlantılar **şəxsi** (konkret istifadəçiyə məxsusdur; onları özü söndürə bilər) və **iş sahəsi üçün paylaşılan** («Workspace shared» teqi ilə işarələnir; şəxsən söndürülə bilməz) olur. Bir provayderə **bir neçə hesab** bağlamaq olar: «+ hesab» düyməsi imza (label) soruşur və eyni provayderin daha bir hesabını saxlayır — məsələn, bir neçə Google təqvimi və ya poçt qutusu. Əsas kimlik məlumatları şəxsi olduğu üçün, bir fəaliyyət iş-sahəsi miqyaslı hesaba deyil, müəyyən bir insanın avtorizasiyasına aid edilməli və onunla məhdudlaşdırılmalı olduqda Bağlantı çox vaxt düzgün alətdir. ## Sonra haraya - [Şəxsi vs paylaşılan kimlik məlumatları](/en/v1.0/access/personal-vs-shared) — tam miqyas modeli və hər birini nə zaman seçmək. - [BYOK LLM provayderləri](/en/v1.0/access/byok-providers) — hər tenant üzrə öz model açarlarınızı gətirin. - [Marketplace icmalı və səviyyələri](/en/v1.0/marketplace/overview-tiers) — OAuth-dəstəkli inteqrasiyaların yeri.