OAuth-ისა და OpenID Connect-ის ილუსტრირებული გზამკვლევი

Შენიშვნა. თარგმნა: Okta-ს ეს შესანიშნავი სტატია განმარტავს, თუ როგორ მუშაობს OAuth და OIDC (OpenID Connect) მარტივი და გასაგები გზით. ეს ცოდნა სასარგებლო იქნება დეველოპერებისთვის, სისტემის ადმინისტრატორებისთვის და პოპულარული ვებ აპლიკაციების „რეგულარული მომხმარებლებისთვისაც“, რომლებიც, სავარაუდოდ, კონფიდენციალურ მონაცემებს სხვა სერვისებთანაც ცვლიან.

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

"მომეცი შენი საბანკო ანგარიში." „გპირდებით, რომ პაროლით და ფულით ყველაფერი კარგად იქნება. ეს გულწრფელია, პატიოსანი! ” *ჰე ჰეი*

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

დღეს არსებობს ერთი სტანდარტი, რომელიც საშუალებას აძლევს ერთ სერვისს უსაფრთხოდ გამოიყენოს მეორის მონაცემები. სამწუხაროდ, ასეთი სტანდარტები იყენებს უამრავ ჟარგონს და ტერმინს, რაც ართულებს მათ გაგებას. ამ მასალის მიზანია ახსნას, თუ როგორ მუშაობენ ისინი მარტივი ილუსტრაციების გამოყენებით (თქვენ გგონიათ, რომ ჩემი ნახატები ჰგავს ბავშვების დალაგებას? ოჰ, კარგი!).

სხვათა შორის, ეს სახელმძღვანელო ასევე ხელმისაწვდომია ვიდეო ფორმატში:

ქალბატონებო და ბატონებო, მოგესალმებით: OAuth 2.0

OAuth 2.0 არის უსაფრთხოების სტანდარტი, რომელიც საშუალებას აძლევს ერთ აპლიკაციას მიიღოს ნებართვა სხვა აპლიკაციაში ინფორმაციის წვდომაზე. ნებართვის გაცემის ნაბიჯების თანმიმდევრობა [ნებართვა] (ან თანხმობა [თანხმობა]) ხშირად რეკავს ავტორიზაცია [ავტორიზაცია] или даже დელეგირებული ავტორიზაცია [დელეგირებული ავტორიზაცია]. ამ სტანდარტით, აპლიკაციას უფლებას აძლევთ წაიკითხოს მონაცემები ან გამოიყენოს სხვა აპლიკაციის ფუნქციები თქვენი სახელით პაროლის მიცემის გარეშე. Კლასი!

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

„დღის სამწუხარო სიტყვა: გსმენიათ ბიჭის შესახებ, რომელმაც სხეულის მარცხენა ნახევარი დაკარგა? ახლა ის ყოველთვის მართალია! ” (დაახლოებითი თარგმანი, რადგან ორიგინალს აქვს თავისი სიტყვა - დაახლ. თარგმანი.)

ნათელია, რომ კონტაქტების სიიდან თითოეულ ადამიანთან მიწერა არ არის ვარიანტი. და, თუ შენც ცოტათი ჩემნაირი ხარ, მაშინ ყველაფერს გააკეთებ, რათა თავიდან აიცილო ზედმეტი სამუშაო. საბედნიეროდ, დღის საშინელი პუბლიკაცია შეუძლია დამოუკიდებლად მოიწვიოს თქვენი ყველა მეგობარი! ამისათვის თქვენ უბრალოდ უნდა გახსნათ წვდომა თქვენი კონტაქტების ელფოსტაზე - საიტი თავად გაუგზავნის მათ მოსაწვევებს (OAuth წესები)!

„ყველას უყვარს კამათი! - Ავტორიზაცია უკვე გავლილია? „გსურთ დაუშვათ დღის საშინელი პუბლიკაცია ვებსაიტს თქვენს კონტაქტების სიაში წვდომისთვის? - Გმადლობთ! ამიერიდან ჩვენ ყოველ დღე გამოგიგზავნით შეხსენებებს ყველას, ვინც იცნობთ, დროის ბოლომდე! შენ საუკეთესო მეგობარი ხარ!"

1. აირჩიეთ თქვენი ელ.ფოსტის სერვისი.
2. საჭიროების შემთხვევაში, გადადით ფოსტის საიტზე და შედით თქვენს ანგარიშზე.
3. მიეცით Terrible Pun of the Day ნებართვა თქვენს კონტაქტებზე წვდომისთვის.
4. დაუბრუნდით დღის საშინელი პუბლიკაციას.

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

OAuth ნაკადი

ჩვენ ახლახან გავიარეთ ის, რასაც ჩვეულებრივ უწოდებენ ნაკადი [ნაკადი] OAuth. ჩვენს მაგალითში ეს ნაკადი შედგება ხილული ნაბიჯებისგან, ასევე რამდენიმე უხილავი საფეხურისგან, რომლებშიც ორი სერვისი თანხმდება ინფორმაციის უსაფრთხო გაცვლაზე. დღის საშინელი სიტყვის წინა მაგალითი იყენებს ყველაზე გავრცელებულ OAuth 2.0 ნაკადს, რომელიც ცნობილია როგორც "ავტორიზაციის კოდის" ნაკადი. ["ავტორიზაციის კოდი" ნაკადი].

სანამ დეტალებს ჩავუღრმავდებით, თუ როგორ მუშაობს OAuth, მოდით ვისაუბროთ რამდენიმე ტერმინის მნიშვნელობაზე:

• რესურსის მფლობელი:

  
  
  Ეს შენ ხარ! თქვენ ფლობთ თქვენს რწმუნებათა სიგელებს, თქვენს მონაცემებს და აკონტროლებთ ყველა აქტივობას, რომელიც შეიძლება შესრულდეს თქვენს ანგარიშებზე.

• კლიენტი:

  
  
  აპლიკაცია (მაგალითად, დღის საშინელი სიტყვის სერვისი), რომელსაც სურს წვდომა ან გარკვეული მოქმედებების შესრულება რესურსის მფლობელი'ა.

• ავტორიზაციის სერვერი:

  
  
  აპლიკაცია, რომელმაც იცის რესურსის მფლობელი'ა და რომელშიც უ რესურსის მფლობელი'უკვე მაქვს ანგარიში.

• რესურს სერვერი:

  
  
  აპლიკაციის პროგრამირების ინტერფეისი (API) ან სერვისი, რომელიც კლიენტი სურს გამოიყენოს სახელით რესურსის მფლობელი'ა.

• გადამისამართება URI:

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

• პასუხის ტიპი:

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

• სფერო:

  
  
  ეს არის საჭირო ნებართვების დეტალური აღწერა კლიენტი'y, როგორიცაა მონაცემების წვდომა ან გარკვეული ქმედებების შესრულება.

• თანხმობა:

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

• კლიენტის ID:

  
  
  ეს ID გამოიყენება იდენტიფიკაციისთვის კლიენტი'ა ავტორიზაციის სერვერი'ე.

• კლიენტის საიდუმლო:

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

• ავტორიზაციის კოდი:

  
  
  დროებითი კოდი მოქმედების ხანმოკლე ვადით, რომელიც კლიენტი უზრუნველყოფს ავტორიზაციის სერვერი-ის სანაცვლოდ წვდომის ჟეტონი.

• წვდომის ჟეტონი:

  
  
  გასაღები, რომელსაც კლიენტი გამოიყენებს კომუნიკაციისთვის რესურს სერვერი'ომ. ერთგვარი სამკერდე ან გასაღები ბარათი, რომელიც უზრუნველყოფს კლიენტიაქვს ნებართვა მოითხოვოს მონაცემები ან განახორციელოს მოქმედებები რესურს სერვერითქვენი სახელით.

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

ახლა, როდესაც ჩვენ განვიხილეთ OAuth 2.0-ის ძირითადი ცნებები, მოდით დავუბრუნდეთ ჩვენს მაგალითს და უფრო ახლოს მივხედოთ რა ხდება OAuth ნაკადში.

1. შენ, რესურსის მფლობელი, გსურთ უზრუნველყოთ დღის საშინელი პუბლიკაცია (კლიენტიშ) წვდომა თქვენს კონტაქტებზე, რათა მათ შეძლონ მოწვევის გაგზავნა ყველა თქვენს მეგობარს.
2. კლიენტი გადამისამართებს ბრაუზერს გვერდზე ავტორიზაციის სერვერი'ა და ჩართეთ შეკითხვაში კლიენტის ID, გადამისამართება URI, პასუხის ტიპი და ერთი ან მეტი ფარგლებში (ნებართვები) სჭირდება.
3. ავტორიზაციის სერვერი ამოწმებს თქვენ, საჭიროების შემთხვევაში ითხოვს მომხმარებლის სახელს და პაროლს.
4. ავტორიზაციის სერვერი აჩვენებს ფორმას თანხმობა (დადასტურებები) ყველა სიით ფარგლებშიმოთხოვნილი კლიენტიომ. თქვენ ეთანხმებით ან უარს.
5. ავტორიზაციის სერვერი გადამისამართებთ თქვენ საიტზე კლიენტია, გამოყენებით გადამისამართება URI ერთად ავტორიზაციის კოდი (ავტორიზაციის კოდი).
6. კლიენტი უშუალოდ ურთიერთობს ავტორიზაციის სერვერი'ohm (ბრაუზერის გვერდის ავლით რესურსის მფლობელია) და უსაფრთხოდ აგზავნის კლიენტის ID, კლიენტის საიდუმლო и ავტორიზაციის კოდი.
7. ავტორიზაციის სერვერი ამოწმებს მონაცემებს და პასუხობს წვდომის ჟეტონი'om (წვდომის ნიშანი).
8. ახლა კლიენტი შეგიძლია გამოიყენო წვდომის ჟეტონი თხოვნის გასაგზავნად რესურს სერვერი კონტაქტების სიის მისაღებად.

კლიენტის ID და საიდუმლო

დიდი ხნით ადრე, ვიდრე თქვენ დაუშვებდით თქვენს კონტაქტებზე წვდომას, კლიენტმა და ავტორიზაციის სერვერმა დაამყარეს სამუშაო ურთიერთობა. ავტორიზაციის სერვერმა შექმნა კლიენტის ID და კლიენტის საიდუმლო (ზოგჯერ იწოდება app ID и აპის საიდუმლო) და გაუგზავნა ისინი კლიენტს OAuth-ის ფარგლებში შემდგომი ურთიერთობისთვის.

"- გამარჯობა! მსურს თქვენთან მუშაობა! - რა თქმა უნდა, არაა პრობლემა! აქ არის თქვენი კლიენტის ID და საიდუმლო!”

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

მაგრამ ეს ყველაფერი არ არის... გთხოვთ, მოგესალმებით OpenID Connect!

OAuth 2.0 განკუთვნილია მხოლოდ ავტორიზაცია - უზრუნველყოს მონაცემებისა და ფუნქციების წვდომა ერთი აპლიკაციიდან მეორეზე. OpenID Connect (OIDC) არის თხელი ფენა OAuth 2.0-ის თავზე, რომელიც ამატებს ანგარიშში შესული მომხმარებლის შესვლისა და პროფილის დეტალებს. შესვლის სესიის ორგანიზებას ხშირად უწოდებენ ავთენტიფიკაცია [ავთენტიფიკაცია], და ინფორმაცია სისტემაში შესული მომხმარებლის შესახებ (ე.ი. შესახებ რესურსის მფლობელიე), - პერსონალური მონაცემები [იდენტობა]. თუ ავტორიზაციის სერვერი მხარს უჭერს OIDC-ს, მას ზოგჯერ უწოდებენ პერსონალური მონაცემების მიმწოდებელი [იდენტიფიკაციის მიმწოდებელი]რადგან ის უზრუნველყოფს კლიენტი"გაქვს ინფორმაცია იმის შესახებ რესურსის მფლობელი'ე.

OpenID Connect საშუალებას გაძლევთ განახორციელოთ სცენარები, სადაც ერთი შესვლა შეიძლება გამოყენებულ იქნას მრავალ აპლიკაციაში - ეს მიდგომა ასევე ცნობილია როგორც ერთი ხელმოწერა (SSO). მაგალითად, აპლიკაციამ შეიძლება მხარი დაუჭიროს SSO ინტეგრაციას სოციალურ ქსელებთან, როგორიცაა Facebook ან Twitter, რაც მომხმარებლებს საშუალებას აძლევს გამოიყენონ ანგარიში, რომელიც უკვე აქვთ და ურჩევნიათ გამოიყენონ.

ნაკადი (ნაკადი) OpenID Connect გამოიყურება იგივე, რაც OAuth-ის შემთხვევაში. ერთადერთი განსხვავება ისაა, რომ პირველად მოთხოვნაში გამოყენებულია კონკრეტული ფარგლები openid, - ა კლიენტი საბოლოოდ ხდება მსგავსი წვდომის ჟეტონიდა ID ჟეტონი.

ისევე, როგორც OAuth ნაკადში, წვდომის ჟეტონი OpenID Connect-ში ეს არის გარკვეული მნიშვნელობა, რომელიც გაუგებარია კლიენტი'ზე. გადმოსახედიდან კლიენტი'ა წვდომის ჟეტონი წარმოადგენს სიმბოლოების სტრიქონს, რომელიც გადაეცემა თითოეულ მოთხოვნას რესურს სერვერი'y, რომელიც განსაზღვრავს თუ არა ჟეტონი მოქმედებს. ID ჟეტონი სულ სხვა რამეს წარმოადგენს.

ID Token არის JWT

ID ჟეტონი არის სპეციალურად ფორმატირებული სიმბოლოების სტრიქონი, რომელიც ცნობილია როგორც JSON Web Token ან JWT (ზოგჯერ JWT ჟეტონები გამოითქმის როგორც "jots"). გარე დამკვირვებლებისთვის JWT შეიძლება გაუგებარ ჭკუაზე ჩანდეს, მაგრამ კლიენტი შეუძლია JWT-დან ამოიღოს სხვადასხვა ინფორმაცია, როგორიცაა ID, მომხმარებლის სახელი, შესვლის დრო, ვადის გასვლის თარიღი ID ჟეტონია, JWT-ში ჩარევის მცდელობების არსებობა. მონაცემები შიგნით ID ჟეტონი"ა-ს უწოდებენ აპლიკაციები [პრეტენზიები].

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

შეიტყვეთ მეტი OAuth-ისა და OIDC-ის შესახებ

ასე რომ, ჩვენ მოკლედ მიმოვიხილეთ, თუ როგორ მუშაობს OAuth და OIDC. მზად ხართ უფრო ღრმად ჩაძიროთ? აქ არის დამატებითი რესურსები, რომლებიც დაგეხმარებათ გაიგოთ მეტი OAuth 2.0 და OpenID Connect-ის შესახებ:

• რა ჯანდაბა არის OAuth?
• არავის აინტერესებს OAuth ან OpenID Connect
• დანერგეთ OAuth 2.0 ავტორიზაციის კოდი PKCE Flow-ით
• რა არის OAuth 2.0 გრანტის ტიპი?
• OAuth 2.0 ბრძანების ხაზიდან
• შექმენით უსაფრთხო Node.js აპლიკაცია SQL სერვერით

როგორც ყოველთვის, მოგერიდებათ კომენტარის გაკეთება. ჩვენი უახლესი ამბების გასაცნობად, გამოიწერეთ Twitter и YouTube Okta დეველოპერებისთვის!

PS მთარგმნელისგან

ასევე წაიკითხეთ ჩვენს ბლოგზე:

• «უსაფრთხოების ABC Kubernetes-ში: ავთენტიფიკაცია, ავტორიზაცია, აუდიტი";
• «მომხმარებლები და ავტორიზაცია RBAC Kubernetes-ში";
• «33+ Kubernetes უსაფრთხოების ინსტრუმენტები";
• «უსაფრთხოება Docker კონტეინერებისთვის".

წყარო: www.habr.com