OpenID Connect: შიდა აპლიკაციების ავტორიზაცია მორგებულიდან სტანდარტამდე

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

დიდი ხნის წინ... როგორ დაიწყო ეს ყველაფერი

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

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

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

საერთო სტანდარტებით

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

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

ჩვენი საკუთარი OIDC სერვერის დანერგვის ჩვენი გზა

1) მიიტანეთ მონაცემები სასურველ ფორმაში

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

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

2) განხორციელდა საჭირო გრანტები

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

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

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

3) დააყენეთ საბაჟო მონაცემების გამომავალი ფორმატები

შერჩეული გრანტების განხორციელების, ავტორიზაციის სამუშაოების შემდეგ, აღსანიშნავია საბოლოო მომხმარებლის შესახებ მონაცემების მიღება. OIDC-ს აქვს ცალკე დასასრული ამისათვის, სადაც შეგიძლიათ მოითხოვოთ მომხმარებლის მონაცემები თქვენი მიმდინარე წვდომის ნიშნით და თუ ის განახლებულია. და თუ მომხმარებლის მონაცემები ასე ხშირად არ იცვლება და თქვენ ბევრჯერ გჭირდებათ მიჰყვეთ მიმდინარეებს, შეგიძლიათ მიხვიდეთ ისეთ გადაწყვეტამდე, როგორიცაა JWT ტოკენები. ეს ნიშნები ასევე მხარდაჭერილია სტანდარტით. თავად JWT ტოკენი შედგება სამი ნაწილისგან: სათაური (ინფორმაცია ტოკენის შესახებ), payload (ნებისმიერი საჭირო მონაცემი) და ხელმოწერა (ხელმოწერა, ჟეტონს ხელს აწერს სერვერი და მოგვიანებით შეგიძლიათ შეამოწმოთ მისი ხელმოწერის წყარო).

OIDC დანერგვისას, JWT ტოკენს ეწოდება id_token. ის შეიძლება მოითხოვოს ჩვეულებრივ წვდომის ჟეტონთან ერთად და რჩება მხოლოდ ხელმოწერის გადამოწმება. ავტორიზაციის სერვერს აქვს ცალკე დასასრული ამისათვის ფორმატში საჯარო გასაღებების სიმრავლით J.W.K.. და ამაზე საუბრისას, აღსანიშნავია, რომ არსებობს კიდევ ერთი საბოლოო წერტილი, რომელიც სტანდარტზე დაყრდნობით RFC5785 ასახავს OIDC სერვერის მიმდინარე კონფიგურაციას. ის შეიცავს ყველა საბოლოო წერტილის მისამართს (მათ შორის, საჯარო გასაღების რგოლის მისამართს, რომელიც გამოიყენება ხელმოწერისთვის), მხარდაჭერილ ბრენდებსა და სკოპებს, გამოყენებული დაშიფვრის ალგორითმებს, მხარდაჭერილ გრანტებს და ა.შ.

მაგალითად Google-ში:

{
 "issuer": "https://accounts.google.com",
 "authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth",
 "device_authorization_endpoint": "https://oauth2.googleapis.com/device/code",
 "token_endpoint": "https://oauth2.googleapis.com/token",
 "userinfo_endpoint": "https://openidconnect.googleapis.com/v1/userinfo",
 "revocation_endpoint": "https://oauth2.googleapis.com/revoke",
 "jwks_uri": "https://www.googleapis.com/oauth2/v3/certs",
 "response_types_supported": [
  "code",
  "token",
  "id_token",
  "code token",
  "code id_token",
  "token id_token",
  "code token id_token",
  "none"
 ],
 "subject_types_supported": [
  "public"
 ],
 "id_token_signing_alg_values_supported": [
  "RS256"
 ],
 "scopes_supported": [
  "openid",
  "email",
  "profile"
 ],
 "token_endpoint_auth_methods_supported": [
  "client_secret_post",
  "client_secret_basic"
 ],
 "claims_supported": [
  "aud",
  "email",
  "email_verified",
  "exp",
  "family_name",
  "given_name",
  "iat",
  "iss",
  "locale",
  "name",
  "picture",
  "sub"
 ],
 "code_challenge_methods_supported": [
  "plain",
  "S256"
 ],
 "grant_types_supported": [
  "authorization_code",
  "refresh_token",
  "urn:ietf:params:oauth:grant-type:device_code",
  "urn:ietf:params:oauth:grant-type:jwt-bearer"
 ]
}

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

განხორციელების შედეგები

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

საუბარი არსებულ გადაწყვეტილებებზე

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

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

Keycloak და Ory Hydra არ არის ერთადერთი გამოსავალი. უმჯობესია აირჩიოთ OpenID Foundation-ის მიერ დამოწმებული განხორციელება. ამ გადაწყვეტილებებს, როგორც წესი, აქვთ OpenID სერტიფიკაციის ბეჯი.

ასევე არ დაივიწყოთ არსებული ფასიანი პროვაიდერები, თუ არ გსურთ თქვენი OIDC სერვერის შენარჩუნება. დღეს ბევრი კარგი ვარიანტია.

რა არის შემდეგი

უახლოეს მომავალში ვაპირებთ სხვაგვარად დავხუროთ შიდა სერვისების ტრაფიკი. ჩვენ ვგეგმავთ გადავიტანოთ ჩვენი ამჟამინდელი SSO ბალანსერზე OpenResty-ის გამოყენებით პროქსიზე, რომელიც დაფუძნებულია OAuth-ზე. აქ უკვე ბევრი მზა გამოსავალია, მაგალითად:
github.com/bitly/oauth2_proxy
github.com/ory/oathkeeper
github.com/keycloak/keycloak-gatekeeper

დამატებითი მასალები

jwt.io – კარგი სერვისი JWT ტოკენების დასადასტურებლად
openid.net/developers/certified - სერტიფიცირებული OIDC განხორციელებების სია

წყარო: www.habr.com