# ავთენტიკაცია {#authentication}

სერვერთან ურთიერთობისთვის CLI-ს სჭირდება მოთხოვნების ავთენტიკაცია [bearer authentication](https://swagger.io/docs/specification/authentication/bearer-authentication/)-ის გამოყენებით. CLI მხარდაჭერას უწევს ავთენტიკაციას როგორც მომხმარებლად, ისე ანგარიშად, ან OIDC ტოკენის გამოყენებით.

## როგორც მომხმარებელი {#as-a-user}

როდესაც CLI-ს იყენებთ ლოკალურად თქვენს მანქანაზე, ჩვენ გირჩევთ ავთენტიკაციას როგორც მომხმარებელი. მომხმარებლად ავთენტიკაციისთვის უნდა გაუშვათ შემდეგი ბრძანება:

```bash
tuist auth login
```

ბრძანება გაგივლით ვებზე დაფუძნებულ ავთენტიკაციის პროცესს. ავთენტიკაციის შემდეგ, CLI შეინახავს ხანგრძლივი ვადის განახლების ტოკენს და მოკლე ვადის წვდომის ტოკენს `~/.config/tuist/credentials` ქვეშ. დირექტორიაში არსებული თითოეული ფაილი წარმოადგენს დომენს, რომლის მიმართაც მოხდა ავთენტიკაცია, რაც ნაგულისხმევად უნდა იყოს `tuist.dev.json`. ამ დირექტორიაში შენახული ინფორმაცია მგრძნობიარეა, ამიტომ **დარწმუნდით, რომ ის უსაფრთხოდ შეინახეთ**.

CLI ავტომატურად მოიძიებს სერთიფიკატებს სერვერთან მოთხოვნების გაკეთებისას. თუ წვდომის ტოკენი ვადაგასულია, CLI გამოიყენებს განახლების ტოკენს ახალი წვდომის ტოკენის მისაღებად.

> [!NOTE]
> თუ თქვენი ორგანიზაცია იყენებს ერთჯერად შესვლას (SSO), ბრაუზერში აირჩიეთ საწარმოს შესვლის ვარიანტი და შეიყვანეთ სამუშაო ელფოსტის მისამართი. Tuist-ს შეუძლია პროვაიდერის პოვნა თქვენი არსებული ორგანიზაციის წევრობიდან ან <.localized_link href="/guides/integrations/authentication/sso#verify-a-login-email-domain">დადასტურებული შესვლის ელფოსტის დომენიდან</.localized_link>.

## OIDC ტოკენები {#oidc-tokens}

CI გარემოებისთვის, რომლებიც მხარს უჭერენ OpenID Connect-ს (OIDC), Tuist-ს შეუძლია ავტომატური ავთენტიკაცია ხანგრძლივი ვადის საიდუმლოების მართვის საჭიროების გარეშე. მხარდაჭერილ CI გარემოში გაშვებისას, CLI ავტომატურად აღმოაჩენს OIDC ტოკენის პროვაიდერს და ცვლის CI-ს მიერ მოწოდებულ ტოკენს Tuist-ის წვდომის ტოკენზე.

### მხარდაჭერილი პროვაიდერები {#supported-ci-providers}

Tuist ცნობს ამ CI პროვაიდერებს და ასახავს მათ ტოკენებს პროექტებზე თქვენი რეპოზიტორიის კავშირის მეშვეობით:

- GitHub Actions
- CircleCI
- Bitrise

ნებისმიერი სხვა იდენტობის პროვაიდერი, რომელიც გასცემს OpenID Connect ტოკენებს, შეუძლია ავთენტიკაცია [workload identity trust policy](#workload-identity-trust-policies)-ის მეშვეობით, რომელსაც ერთხელ აკონფიგურირებთ თქვენი ანგარიშის ყველა მიმდინარე და მომავალი პროექტისთვის, მაგალითად [Fly.io Machines](#flyio-machines).

### OIDC ავთენტიკაციის დაყენება {#setting-up-oidc-authentication}

GitHub Actions-ის, CircleCI-ის და Bitrise-ისთვის:

1. **დააკავშირეთ თქვენი რეპოზიტორია Tuist-თან**: მიჰყევით <.localized_link href="/guides/integrations/gitforge/github">GitHub ინტეგრაციის სახელმძღვანელოს</.localized_link>, რათა დააკავშიროთ თქვენი GitHub რეპოზიტორია თქვენს Tuist პროექტთან.

2. **გაუშვით `tuist auth login`**: თქვენს CI სამუშაო პროცესში, გაუშვით `tuist auth login` ნებისმიერ ბრძანებამდე, რომელიც მოითხოვს ავთენტიკაციას. CLI ავტომატურად აღმოაჩენს CI გარემოს და ავთენტიკაციას მოახდენს OIDC-ის გამოყენებით.

იხილეთ <.localized_link href="/guides/integrations/continuous-integration">Continuous Integration სახელმძღვანელო</.localized_link> პროვაიდერის სპეციფიკური კონფიგურაციის მაგალითებისთვის.

### Workload identity trust policies {#workload-identity-trust-policies}

ნდობის პოლიტიკა საშუალებას აძლევს სხვა იდენტობის პროვაიდერის workloads-ს, როგორიცაა განლაგების პლატფორმა, Kubernetes კლასტერი ან თვითმართვადი CI სისტემა, მიიღონ წვდომა პროექტზე ხანგრძლივი ვადის Tuist საიდუმლოს გარეშე. პროვაიდერმა უნდა:

- იყოს ხელმისაწვდომი HTTPS-ით საჯარო მისამართზე. Tuist არ მიჰყვება გადამისამართებებს და არ უკავშირდება პირად ან შიდა ქსელის მისამართებს, მათ შორის თვითმასპინძელი Tuist სერვერებიდან.
- გასცეს JWT-ები, ხელმოწერილი ასიმეტრიული გასაღებით, მაგალითად `RS256` ან `ES256`. ხელმოუწერილი ტოკენები და ტოკენები, ხელმოწერილი გაზიარებული საიდუმლოთი (`HS256` და მსგავსი), უარყოფილია.
- გამოაქვეყნოს თავისი ხელმოწერის გასაღებები JSON Web Key Set-ად (JWKS) ფიქსირებულ HTTPS URL-ზე. პასუხი უნდა იყოს მაქსიმუმ 64 KiB და შეიცავდეს მაქსიმუმ 20 გასაღებს.
- შეიცავდეს ვადის გასვლას (`exp`) ყოველ ტოკენში.

GitHub Actions-ის, CircleCI-ის და Bitrise-ის გამცემები რეზერვირებულია ზემოთ აღწერილი რეპოზიტორიაზე დაფუძნებული ნაკადისთვის და არ შეიძლება მათი გამოყენება ნდობის პოლიტიკაში.

> [!NOTE]
> თვითმასპინძელი განლაგებისთვის, გამოიყენეთ მონაცემთა ბაზის მიგრაციები და განაახლეთ Tuist სერვერის ყოველი მომსახურე რეპლიკა workload identities-ის კონფიგურაციამდე ან სამუშაოების მათზე გადატანამდე. შემდეგ განაახლეთ CLI ან Elixir ინტეგრაცია ვერსიამდე, რომელიც მხარს უჭერს `TUIST_OIDC_TOKEN` და `TUIST_OIDC_ACCOUNT`. არსებული GitHub Actions-ის, CircleCI-ის და Bitrise-ის სამუშაოები აგრძელებენ რეპოზიტორიაზე დაფუძნებული ავტორიზაციის გამოყენებას და არ საჭიროებენ ანგარიშის handle-ს. პროდუქციის სამუშაოებზე გადასვლამდე, შეამოწმეთ მოკლე ვადის ტოკენის გაცვლა და cache ოპერაცია სასურველ workload-თან. ახალი გაცვლების შესაჩერებლად, წაშალეთ პოლიტიკა; მიეცით ერთ საათამდე დრო უკვე გაცემული Tuist წვდომის ტოკენების ვადის გასვლისთვის. პოლიტიკის წაშლა არ აუქმებს დაუყოვნებლივ ამ ტოკენებს.

#### პოლიტიკის შექმნა {#create-a-trust-policy}

Tuist dashboard-ში, გახსენით თქვენი ანგარიშის **Settings** > **Authentication** და იპოვეთ **Workload identities** სექცია. თქვენ უნდა იყოთ ანგარიშის ადმინისტრატორი (ან პირადი ანგარიშის მფლობელი). თითოეულ ანგარიშს შეიძლება ჰქონდეს მაქსიმუმ 20 პოლიტიკა. კონფიგურაცია მოახდინეთ იდენტობის ერთხელ ანგარიშის მასშტაბით CI წვდომისთვის; პროექტის შერჩევა არ არის საჭირო.

გამოიყენეთ გადამრთველი **Workload identities**-ის გვერდით პოლიტიკის ფორმის გასახსნელად. გადამრთველი ირთვება, როდესაც ანგარიშს აქვს შენახული იდენტობები და რჩება ჩართული შენახვის შემდეგ. ის იწყება გამორთული ანგარიშებისთვის იდენტობების გარეშე. სექცია ჩნდება **SCIM provisioning**-ის ქვემოთ ორგანიზაციებისთვის. ფორმის დამალვა ინარჩუნებს თქვენს პროექტს და არ თიშავს workload ავთენტიკაციას: შენახული იდენტობის ბარათები და დაყენების დოკუმენტაციის ბმული რჩება ხილული. თითოეული ბარათი აჩვენებს იდენტობის სახელს, გამცემის და JWKS URL-ებს, აუდიენციას, ზუსტ JSON claims-ებს, ანგარიშის მასშტაბის მოცულობას და შექმნის დროს. წაშალეთ იდენტობა მის ბარათზე არსებული მოქმედების გამოყენებით.

აირჩიეთ **Custom provider** ქვემოთ მოცემული ველების შესაყვანად, ან **Fly.io Machines** მათი გენერირებისთვის თქვენი ორგანიზაციის slug-ის და რიცხვითი ორგანიზაციის და აპლიკაციის ID-ებისგან. Fly შაბლონი ინარჩუნებს გენერირებულ გამცემს, JWKS URL-ს და claims-ებს რედაქტირებადს **Advanced configuration**-ის ქვეშ. შაბლონების ან დამხმარე მნიშვნელობების შეცვლა ინარჩუნებს ხელით რედაქტირებულ ველებს. თუ თქვენი გამცემი, JWKS URL ან claims-ები გადაფარავს შაბლონს, Tuist გააფართოებს **Advanced configuration**-ს და აჩვენებს გაფრთხილებას, რათა შეძლოთ შენახული პოლიტიკის გადახედვა. დაუბრუნდით **Custom provider**-ს Fly-ის დამხმარეების გარეშე გასაგრძელებლად. შაბლონები მხოლოდ ავსებენ კონფიგურაციას და არ ცვლიან იმას, თუ როგორ ამოწმებს Tuist ტოკენებს.

| ველი | აღწერა |
| --- | --- |
| სახელი | პოლიტიკის ამოსაცნობი ლეიბლი, უნიკალური ანგარიშის ფარგლებში. |
| გამცემის URL | ტოკენის `iss` claim. ის უნდა ემთხვეოდეს ზუსტად, ნებისმიერი ბოლო სლეშის ჩათვლით. |
| JWKS URL | პროვაიდერის ხელმოწერის გასაღებების HTTPS URL. Tuist იყენებს ამ URL-ს პირდაპირ და არ კითხულობს პროვაიდერის OpenID Connect აღმოჩენის დოკუმენტს, ამიტომ დააკოპირეთ `jwks_uri` პროვაიდერის დოკუმენტაციიდან ან `<issuer>/.well-known/openid-configuration`-დან. |
| აუდიტორია | აუდიტორია, რომლისთვისაც უნდა გაიცეს ტოკენი, ნაგულისხმევად `tuist`. ტოკენის `aud` უნდა ემთხვეოდეს მას ან, როცა `aud` სიაა, შეიცავდეს მას. გამოიყენეთ მნიშვნელობა, რომელსაც მხოლოდ Tuist იღებს, რათა სხვა სერვისებისთვის გამოშვებული ტოკენები ვერ განმეორდეს აქ. |
| Claims | JSON ობიექტი 1-დან 10-მდე claim-ით, რომელიც ტოკენმა უნდა შეიცავდეს, მაგალითად `{"sub": "system:serviceaccount:ci:builder"}`. JSON შეყვანა შემოიფარგლება 8 KiB-ით. მნიშვნელობები უნდა იყოს სტრინგები, ნიშნიანი 64-ბიტიანი მთელი რიცხვები ან ბულიანები და ისინი უნდა ემთხვეოდნენ ზუსტად, მათი ტიპის ჩათვლით: `"123"` არ ემთხვევა `123`-ს. ჩადგმული ობიექტები, სიები და დროის ან ტოკენის claims-ები, როგორიცაა `iss`, `aud`, `exp`, `nbf`, `iat` და `jti`, არ არის დაშვებული. |

თითოეული პოლიტიკა ანიჭებს CI წვდომას **ანგარიშის კუთვნილ ყველა მიმდინარე და მომავალ პროექტზე**, ინდივიდუალური პროექტების შერჩევის გარეშე. თქვენ შეგიძლიათ დააკონფიგურიროთ იდენტობა პირველი პროექტის შექმნამდე. ეს არ ანიჭებს ანგარიშის ადმინისტრირებას ან წვდომას სხვა ანგარიშზე.

ნებისმიერი სამუშაო დატვირთვა, რომელსაც შეუძლია მიიღოს ტოკენი შესაბამისი claims-ებით, შეუძლია წვდომა ჰქონდეს ყველა ამ პროექტზე, ამიტომ აირჩიეთ claims-ები, რომლებსაც პროვაიდერი გარანტირებს და რომელთა ხელახლა გამოყენება ვერავის შეუძლია. უპირატესობა მიანიჭეთ სტაბილურ რიცხვით ID-ებს სახელების ნაცვლად, რომლებიც შეიძლება გადაერქვა ან ხელახლა დარეგისტრირდეს წაშლის შემდეგ.

> [!WARNING]
> გაზიარებულ იდენტობის პროვაიდერზე, დააკავშირეთ პოლიტიკა თქვენს ორგანიზაციას ან არენდატორს **და** სასურველ აპლიკაციას, პროექტს ან სერვისის ანგარიშს. შტოს სახელი, როგორიცაა `main`, გარემო, როგორიცაა `production`, ან ზოგადი როლი მარტო არ არის იდენტობის საზღვარი: სხვა არენდატორმა შეიძლება მიიღოს ტოკენი იგივე მნიშვნელობებით. მაგალითად, GitLab.com პოლიტიკამ უნდა შეიცავდეს სასურველი პროექტის სტაბილურ `project_id`-ს, არა მხოლოდ `ref`-ს. შესაბამისი ტოკენი ანიჭებს ანგარიშის მასშტაბით CI წვდომას, cache-ში ჩაწერის ჩათვლით, ამიტომ პოლიტიკამ, რომელიც ენდობა არარელევანტურ სამუშაო დატვირთვებს, შეიძლება დაუშვას cache-ის მოწამვლა.

Tuist ანიჭებს წვდომას მხოლოდ იმ პოლიტიკებისთვის, რომელთა საკუთარი JWKS URL შეიცავს გასაღებს, რომლითაც ტოკენი არის ხელმოწერილი, გამცემის, აუდიტორიის, ვადის, not-before დროის (60 წამამდე საათის ცდომილებით) და ყოველი claim-ის შემოწმების შემდეგ. გამოშვებული ერთსაათიანი CI ტოკენი არის ანგარიშის მასშტაბით, არა პროექტების ID-ების სნეპშოტი: ის მოიცავს პროექტებს, რომლებიც შეიქმნა ან გადაიტანეს ანგარიშზე გამოშვების შემდეგ. პროექტის ავტორიზაცია კვლავ მოითხოვს მიმდინარე ანგარიშის კუთვნილებას, ამიტომ პროექტის გადატანა აშორებს მის წვდომას ამ ანგარიშის ტოკენის ქვეშ.

#### სამუშაო დატვირთვის ავტენტიკაცია {#authenticate-a-workload}

1. მოითხოვეთ იდენტობის ტოკენი თქვენი პროვაიდერისგან პოლიტიკის აუდიტორიით.
2. დააყენეთ `TUIST_OIDC_TOKEN` ამ ტოკენზე და `TUIST_OIDC_ACCOUNT` იმ Tuist ანგარიშის handle-ზე, რომელსაც ეკუთვნის პროექტი. ანგარიში საჭიროა ყოველი trust policy გაცვლისთვის. ის მხოლოდ ირჩევს სად უნდა მოხდეს ძიება და თავისთავად არაფერს ანიჭებს.
3. გაუშვით `tuist auth login`. Elixir პროექტებისთვის, შეგიძლიათ გამოიყენოთ `mix tuist.login` ამის ნაცვლად, ან დაუშვათ Elixir ინტეგრაციამ ავტომატურად გაცვალოს ტოკენი, როცა არ არის ხელმისაწვდომი `TUIST_TOKEN` ან ვალიდური შენახული სერთიფიკატები.

მიღებულ Tuist წვდომის ტოკენს აქვს მხოლოდ `ci` scope ჯგუფი და მოიცავს არჩეული ანგარიშის კუთვნილ ყველა მიმდინარე და მომავალ პროექტს. გაცვლები მარცხდება, თუ ანგარიშში 20-ზე მეტი პოლიტიკა ემთხვევა ერთსა და იმავე ტოკენს ან თუ ისინი იყენებენ ორზე მეტ განსხვავებულ JWKS URL-ს.

Tuist არ აახლებს ამ სესიებს. წვდომის ტოკენები იწურება ერთი საათის შემდეგ და არ აქვთ განახლების ტოკენი. პროვაიდერის იდენტობის ტოკენები ხშირად ვალიდურია მხოლოდ რამდენიმე წუთის განმავლობაში, ამიტომ ძველი `TUIST_OIDC_TOKEN`-ის შენახვა არ არის განახლების სტრატეგია: სამუშაოებისთვის, რომლებიც ერთ საათზე მეტხანს გრძელდება, მოითხოვეთ ახალი იდენტობის ტოკენი და ხელახლა შედით სისტემაში Tuist სესიის ამოწურვამდე. პოლიტიკის წაშლა აჩერებს ახალ გაცვლებს, მაგრამ უკვე გამოშვებული წვდომის ტოკენები რჩება ვალიდურად მათ ამოწურვამდე.

Tuist აქეშირებს პროვაიდერის ხელმოწერის გასაღებებს 15 წუთის განმავლობაში წარმატებული მიღების შემდეგ სპეციალურ, ზომით შეზღუდულ cache-ში. ჩანაწერები შეიძლება ადრე ამოიღონ და ხელახლა მიიღონ. წარუმატებელი მიღებები არ აქეშირდება. თუ თქვენი პროვაიდერი აბრუნავს გასაღებებს, მან უნდა გამოაქვეყნოს ახალი გასაღები თავის JWKS-ში ტოკენებით მისი ხელმოწერამდე სულ მცირე 15 წუთით ადრე, რადგან ტოკენები, რომლებიც ხელმოწერილია გასაღებით, რომელიც არ არის აქეშირებულ ნაკრებში, უარყოფილი იქნება cache-ის ამოწურვამდე. ტოკენები გასაღების ID-ის (`kid`) გარეშე მიღებულია მხოლოდ მაშინ, როცა JWKS შეიცავს ერთ შესაბამის ხელმოწერის გასაღებს. როცა JWKS-ში არის გასაღების ID, ის უნდა იყოს სტრინგი მაქსიმუმ 256 ბაიტისა.

> [!NOTE]
> `TUIST_OIDC_TOKEN` არის ზოგადი ტოკენის შეყვანა, არა სერვერის ნდობის გვერდის ავლის გზა. ის უპირატესობას ანიჭებს CI პროვაიდერის აღმოჩენას და სერვერი კვლავ იღებს მხოლოდ ჩაშენებულ პროვაიდერებს და იდენტობებს შესაბამისი trust policy-ით. არ ჩადოთ იდენტობის ტოკენი `TUIST_TOKEN`-ში, რომელიც ელოდება Tuist სერთიფიკატს.

თუ გაცვლა ვერ მოხერხდა, შეამოწმეთ, რომ გამცემი, აუდიტორია და პოლიტიკის ყოველი claim ზუსტად ემთხვევა ტოკენს, რომ JWKS URL ემსახურება გასაღებს, რომლითაც ტოკენი არის ხელმოწერილი, რომ პოლიტიკა არ არის წაშლილი და რომ `TUIST_OIDC_ACCOUNT` ასახელებს ანგარიშს, რომელსაც ეკუთვნის პროექტი. იმის თავიდან ასაცილებლად, თუ რომელი იდენტობებია სანდო, Tuist აბრუნებს იგივე შეცდომას ყველა ამ შემთხვევისთვის.

### Fly.io Machines {#flyio-machines}

[Fly.io მხარს უჭერს OIDC სამუშაო დატვირთვის იდენტობას](https://docs.fly.io/reference/openid-connect/). Machine-ს შეუძლია მოითხოვოს მოკლევადიანი, ხელმოწერილი იდენტობის ტოკენი თავისი ლოკალური `/.fly/api` Unix socket-იდან, Fly API ტოკენის ან ხანგრძლივი Tuist საიდუმლოს გარეშე. Fly ტოკენები აიდენტიფიცირებენ ორგანიზაციას და აპლიკაციას, არა საწყის რეპოზიტორიას, ამიტომ გამოიყენეთ trust policy GitHub რეპოზიტორიის დაკავშირების ნაცვლად:

1. მიიღეთ გამცემი (`iss`), ორგანიზაციის ID (`org_id`) და აპლიკაციის ID (`app_id`) თქვენს Fly Machine-ში გამოშვებული იდენტობის ტოკენიდან. გამცემია `https://oidc.fly.io/<organization-slug>`. გამოიყენეთ რიცხვითი ID-ები, არა ორგანიზაციის ან აპის სახელები.
2. [შექმენით trust policy](#create-a-trust-policy) **Fly.io Machines** შაბლონის გამოყენებით და შეიყვანეთ ორგანიზაციის slug და ორივე რიცხვითი ID. ის ავსებს ქვემოთ მოცემულ მნიშვნელობებს და ინარჩუნებს ID-ებს სტრინგებად. ასევე შეგიძლიათ შეიყვანოთ ისინი ხელით **Custom provider**-ის გამოყენებით; შეინარჩუნეთ ბრჭყალები ID-ების გარშემო claims-ებში.

   | ველი | მნიშვნელობა |
   | --- | --- |
   | გამცემის URL | `https://oidc.fly.io/<organization-slug>` |
   | JWKS URL | `https://oidc.fly.io/<organization-slug>/.well-known/jwks` |
   | აუდიტორია | `tuist` |
   | Claims | `{"org_id": "<organization-id>", "app_id": "<application-id>"}` |

3. Machine-ის შიგნით, დააყენეთ `TUIST_OIDC_ACCOUNT` Tuist ანგარიშის handle-ზე, რომელსაც ეკუთვნის პროექტი (არა Fly ორგანიზაციის slug), მოითხოვეთ ტოკენი აუდიტორიით `tuist` და გადაეცით ის `tuist auth login`-ს `TUIST_OIDC_TOKEN`-ის გამოყენებით:

```bash
set -euo pipefail
export TUIST_OIDC_ACCOUNT="my-tuist-account"

TUIST_OIDC_TOKEN="$(curl --fail --silent --show-error \
  --unix-socket /.fly/api \
  -X POST http://localhost/v1/tokens/oidc \
  -H 'Content-Type: application/json' \
  --data '{"aud":"tuist"}')"
export TUIST_OIDC_TOKEN

tuist auth login
unset TUIST_OIDC_TOKEN
```

საწყისი კონფიგურაციისთვის, შეგიძლიათ შეამოწმოთ მხოლოდ იდენტობის ველები ლოკალურად, ტოკენის ექსპორტირების შემდეგ და მისი გაუქმებამდე. ეს დეკოდირებს claims-ებს კონფიგურაციისთვის; Tuist ცალკე ამოწმებს ხელმოწერას ავტორიზაციის დროს:

```bash
python3 - <<'PY'
import base64, json, os
payload = os.environ["TUIST_OIDC_TOKEN"].split(".")[1]
claims = json.loads(base64.urlsafe_b64decode(payload + "=" * (-len(payload) % 4)))
print(json.dumps({key: claims[key] for key in ("iss", "org_id", "app_id")}, indent=2))
PY
```

არ დაბეჭდოთ ან არ ჩააკომიტოთ თავად ტოკენი. ნებისმიერ Machine-ს ავტორიზებულ Fly აპში შეუძლია ავტორიზაცია Tuist ანგარიშის ყველა მიმდინარე და მომავალ პროექტზე. შექმენით ცალკე policy თითოეული დამატებითი აპისთვის. Fly იდენტობის ტოკენები იწურება დაახლოებით ათ წუთში, ამიტომ ხანგრძლივად მომუშავე Machine-ებზე მოითხოვეთ ახალი და გაუშვით `tuist auth login` ისევ ერთსაათიანი Tuist სესიის ამოწურვამდე.

### OIDC ტოკენის სკოპები {#oidc-token-scopes}

OIDC ტოკენებს ენიჭებათ `ci` სკოპების ჯგუფი. GitHub Actions-ის, CircleCI-ისა და Bitrise-ისთვის, ეს უზრუნველყოფს წვდომას რეპოზიტორიასთან დაკავშირებულ ყველა პროექტზე. სამუშაო დატვირთვის იდენტობის trust policies-ისთვის, ეს უზრუნველყოფს წვდომას შერჩეული ანგარიშის ყველა მიმდინარე და მომავალ პროექტზე, პროექტის შექმნის, პროექტის ადმინისტრირების, runner-ის ადმინისტრირების ან ანგარიშის წევრების ადმინისტრირების უფლების მინიჭების გარეშე. იხილეთ [სკოპების ჯგუფები](#scope-groups) დეტალებისთვის, თუ რას მოიცავს `ci` სკოპი.

> [!TIP]
> **უსაფრთხოების უპირატესობები**
>
> OIDC ავტორიზაცია უფრო უსაფრთხოა ვიდრე ხანგრძლივი ტოკენები, რადგან:
> - არ არის საიდუმლოებები, რომლებიც უნდა განახლდეს ან იმართოს
> - ტოკენები მოკლევადიანია
> - ავტორიზაცია მიბმულია თქვენს რეპოზიტორიის იდენტობაზე ან ცალსახად ავტორიზებულ სამუშაო დატვირთვის იდენტობაზე


## Gradle პლაგინის ავტორიზაცია {#gradle-plugin-authentication}

Gradle პლაგინი იყენებს Tuist CLI ავტორიზაციის მდგომარეობას და არ განსაზღვრავს ცალკე შესვლის ნაკადს. გაიარეთ ავტორიზაცია ერთხელ CLI-ით და პლაგინი ხელახლა გამოიყენებს ამ მონაცემებს.

პროექტისა და სერვერის კონფიგურაციისთვის, `project` და `url` ჩათვლით, გამოიყენეთ კანონიკური <.localized_link href="/references/tuist-toml">tuist.toml მითითება</.localized_link>.

ლოკალური გამოყენებისთვის, გაუშვით:

```bash
tuist auth login
```

CI-სთვის, გამოიყენეთ ერთ-ერთი:

- <.localized_link href="/guides/server/authentication#setting-up-oidc-authentication">OIDC ავტორიზაცია</.localized_link> (რეკომენდებულია, როცა ხელმისაწვდომია)
- <.localized_link href="/guides/server/authentication#continuous-integration">ანგარიშის ტოკენის ავტორიზაცია</.localized_link> `TUIST_TOKEN`-ის მეშვეობით

თვითმასპინძელი Tuist სერვერებისთვის, განსაზღვრეთ სერვერის URL `tuist.toml`-ში (მაგალითად `url = "https://tuist.your-company.com"`) და გაუშვით სტანდარტული შესვლის ნაკადი. URL იხსნება იმავე კონფიგურაციის ფაილიდან, რომელსაც პლაგინი იყენებს.

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

## ანგარიშის ტოკენები {#account-tokens}

CI გარემოებისთვის, რომლებიც არ უჭერენ მხარს OIDC-ს, ან როცა გჭირდებათ ნებართვებზე ზუსტი კონტროლი, შეგიძლიათ გამოიყენოთ ანგარიშის ტოკენები. ანგარიშის ტოკენები საშუალებას გაძლევთ ზუსტად მიუთითოთ, თუ რომელ სკოპებსა და პროექტებზე აქვს ტოკენს წვდომა.

### ანგარიშის ტოკენის შექმნა {#creating-an-account-token}

ანგარიშის ტოკენის შექმნის ყველაზე მარტივი გზა dashboard-იდან არის:

1. გახსენით ორგანიზაცია Tuist dashboard-ში.
2. გადადით **Settings** > **Tokens**-ზე.
3. აირჩიეთ **Generate token**.
4. აირჩიეთ სახელი, არასავალდებულო ვადა, პროექტზე წვდომა და სკოპები, რომლებიც ტოკენს სჭირდება.
5. დააკოპირეთ გენერირებული ტოკენის მნიშვნელობა დიალოგის დახურვამდე. ტოკენის მნიშვნელობები ნაჩვენებია მხოლოდ ერთხელ.

ასევე შეგიძლიათ შექმნათ ანგარიშის ტოკენები CLI-დან, რაც სასარგებლოა სკრიპტინგის ან ავტომატიზაციისთვის:

```bash
tuist account tokens create account-handle \
  --scopes account:cache:write project:cache:read project:cache:write \
  --name ci-cache-token \
  --expires 1y
```

> [!IMPORTANT]
> ჩაანაცვლეთ `account-handle` იმ ანგარიშის handle-ით, რომელსაც ეკუთვნის პროექტები, რომლებზეც გსურთ ტოკენს ჰქონდეს წვდომა. ეს შეიძლება იყოს ორგანიზაციის ანგარიში, არა აუცილებლად თქვენი პირადი ანგარიში.

ბრძანება იღებს შემდეგ პარამეტრებს:

| პარამეტრი | აღწერა |
| --- | --- |
| `--scopes` | სავალდებულო. სკოპების კომებით გამოყოფილი სია, რომლებიც ტოკენს უნდა მიენიჭოს. |
| `--name` | სავალდებულო. ტოკენის უნიკალური იდენტიფიკატორი (1-32 სიმბოლო, მხოლოდ ალფანუმერული, დეფისები და ქვედა ტირეები). |
| `--expires` | არასავალდებულო. როდის უნდა ამოიწუროს ტოკენი. გამოიყენეთ ფორმატი, როგორიცაა `30d` (დღეები), `6m` (თვეები), ან `1y` (წლები). თუ არ არის მითითებული, ტოკენი არასდროს იწურება. |
| `--projects` | შეზღუდეთ ტოკენი კონკრეტული პროექტის handle-ებზე. ტოკენს აქვს წვდომა ყველა პროექტზე, თუ არ არის მითითებული. |

### ხელმისაწვდომი სკოპები {#available-scopes}

| სკოპი | აღწერა |
| --- | --- |
| `account:cache:read` | ანგარიშის სკოპის ქეშირებული ბინარების ჩამოტვირთვა |
| `account:cache:write` | ანგარიშის სკოპის ქეშირებული ბინარების ატვირთვა |
| `account:members:read` | ანგარიშის წევრების წაკითხვა |
| `account:members:write` | ანგარიშის წევრების მართვა |
| `account:registry:read` | Swift-ის პაკეტების რეესტრიდან წაკითხვა |
| `account:registry:write` | Swift-ის პაკეტების რეესტრში გამოქვეყნება |
| `account:runners:read` | runner-ის დავალებების, სამუშაო ნაკადების, პროფილების და ტომების წაკითხვა |
| `account:runners:write` | runner-ის პროფილების მართვა და runner-ის ტომების გასუფთავება |
| `project:previews:read` | პრევიუების ჩამოტვირთვა |
| `project:previews:write` | პრევიუების ატვირთვა |
| `project:admin:read` | პროექტების და მათი პარამეტრების წაკითხვა |
| `project:admin:write` | პროექტების შექმნა, განახლება და წაშლა. პროექტის შესაქმნელად საჭიროა ტოკენი, რომელსაც აქვს წვდომა ყველა პროექტზე |
| `project:cache:read` | ქეშირებული ბინარების ჩამოტვირთვა |
| `project:cache:write` | ქეშირებული ბინარების ატვირთვა |
| `project:bundles:read` | ბანდლების ნახვა |
| `project:bundles:write` | ბანდლების ატვირთვა |
| `project:tests:read` | ტესტის შედეგების წაკითხვა |
| `project:tests:write` | ტესტის შედეგების ატვირთვა |
| `project:builds:read` | აგების ანალიტიკის წაკითხვა |
| `project:builds:write` | აგების ანალიტიკის ატვირთვა |
| `project:runs:read` | ბრძანებების გაშვებების წაკითხვა |
| `project:runs:write` | ბრძანებების გაშვებების შექმნა და განახლება |

### სკოპების ჯგუფები {#scope-groups}

სკოპების ჯგუფები უზრუნველყოფს მოსახერხებელ გზას რამდენიმე დაკავშირებული სკოპის ერთი იდენტიფიკატორით მინიჭებისთვის. როდესაც იყენებთ სკოპების ჯგუფს, ის ავტომატურად ფართოვდება და მოიცავს ყველა ინდივიდუალურ სკოპს, რომელიც მასში შედის.

| სკოპების ჯგუფი | შემავალი სკოპები |
| --- | --- |
| `ci` | `account:cache:write`, `project:cache:write`, `project:previews:write`, `project:bundles:write`, `project:tests:write`, `project:builds:write`, `project:runs:write` |
| `mcp` | `project:cache:read`, `project:previews:read`, `project:bundles:read`, `project:tests:read`, `project:builds:read`, `project:runs:read` |

### უწყვეტი ინტეგრაცია {#continuous-integration}

CI გარემოებისთვის, რომლებიც არ უჭერენ მხარს OIDC-ს, შექმენით ანგარიშის ტოკენი `ci` სკოპების ჯგუფით თქვენი CI სამუშაო ნაკადების ავთენტიფიკაციისთვის. დაფაზე აირჩიეთ **CI** პრესეტი ტოკენის გენერირებისას.

ასევე შეგიძლიათ შექმნათ იგივე ტოკენი CLI-დან:

```bash
tuist account tokens create account-handle --scopes ci --name ci
```

ეს ქმნის ტოკენს ყველა იმ სკოპით, რაც საჭიროა ტიპური CI ოპერაციებისთვის (ქეში, პრევიუები, ბანდლები, ტესტები, აგებები და გაშვებები). შეინახეთ გენერირებული ტოკენი როგორც საიდუმლო თქვენს CI გარემოში და დააყენეთ ის როგორც `TUIST_TOKEN` გარემოს ცვლადი.

### ანგარიშის ტოკენების მართვა {#managing-account-tokens}

გახსენით **Settings** > **Tokens** ანგარიშის დაფაზე, რათა ნახოთ ანგარიშის ტოკენები, შეამოწმოთ ტოკენის სკოპები და პროექტზე წვდომა, და გააუქმოთ ტოკენები როტაციის დროს.

ანგარიშის ყველა ტოკენის ჩამოსათვლელად:

```bash
tuist account tokens list account-handle
```

ტოკენის სახელით გასაუქმებლად:

```bash
tuist account tokens revoke account-handle ci-cache-token
```

### ანგარიშის ტოკენების გამოყენება {#using-account-tokens}

ანგარიშის ტოკენები მოსალოდნელია, რომ განისაზღვროს როგორც გარემოს ცვლადი `TUIST_TOKEN`:

```bash
export TUIST_TOKEN=your-account-token
```

> [!TIP]
> **როდის გამოვიყენოთ ანგარიშის ტოკენები**
>
> გამოიყენეთ ანგარიშის ტოკენები, როდესაც გჭირდებათ:
> - ავთენტიფიკაცია CI გარემოებში, რომლებიც არ უჭერენ მხარს OIDC-ს
> - დაწვრილებითი კონტროლი იმაზე, თუ რომელ ოპერაციებს შეასრულებს ტოკენი
> - ტოკენი, რომელსაც შეუძლია წვდომა ანგარიშში არსებულ რამდენიმე პროექტზე
> - დროით შეზღუდული ტოკენები, რომლებიც ავტომატურად იწურება