OpenID Connect៖ ការអនុញ្ញាតនៃកម្មវិធីខាងក្នុងពីផ្ទាល់ខ្លួនទៅស្តង់ដារ

ប៉ុន្មានខែមុននេះ ខ្ញុំកំពុងអនុវត្តម៉ាស៊ីនមេ OpenID Connect ដើម្បីគ្រប់គ្រងការចូលប្រើសម្រាប់កម្មវិធីខាងក្នុងរាប់រយរបស់យើង។ ពីការអភិវឌ្ឍន៍ផ្ទាល់ខ្លួនរបស់យើង ភាពងាយស្រួលក្នុងទំហំតូច យើងបានផ្លាស់ប្តូរទៅស្តង់ដារដែលទទួលយកជាទូទៅ។ ការចូលប្រើសេវាកម្មកណ្តាលជួយសម្រួលដល់ប្រតិបត្តិការឯកត្តជន កាត់បន្ថយការចំណាយលើការអនុវត្តការអនុញ្ញាត អនុញ្ញាតឱ្យអ្នកស្វែងរកដំណោះស្រាយដែលត្រៀមរួចជាស្រេចជាច្រើន និងមិនធ្វើឱ្យខួរក្បាលរបស់អ្នកខូចនៅពេលបង្កើតកម្មវិធីថ្មី។ នៅក្នុងអត្ថបទនេះ ខ្ញុំនឹងនិយាយអំពីការផ្លាស់ប្តូរនេះ និងការរលាក់ដែលយើងបានគ្រប់គ្រងដើម្បីបំពេញ។

តាំងពីយូរយារណាស់មកហើយ... របៀបដែលវាបានចាប់ផ្តើម

កាលពីប៉ុន្មានឆ្នាំមុន នៅពេលដែលមានកម្មវិធីខាងក្នុងច្រើនពេកសម្រាប់ការគ្រប់គ្រងដោយដៃ យើងបានសរសេរកម្មវិធីដើម្បីគ្រប់គ្រងការចូលប្រើនៅក្នុងក្រុមហ៊ុន។ វាគឺជាកម្មវិធី Rails ដ៏សាមញ្ញមួយ ដែលភ្ជាប់ទៅមូលដ្ឋានទិន្នន័យដែលមានព័ត៌មានអំពីបុគ្គលិក ដែលការចូលប្រើមុខងារផ្សេងៗត្រូវបានកំណត់រចនាសម្ព័ន្ធ។ ជាមួយគ្នានេះ យើងបានលើកឡើងនូវ SSO ទីមួយ ដែលផ្អែកលើការផ្ទៀងផ្ទាត់សញ្ញាសម្ងាត់ពីផ្នែកម្ខាងនៃម៉ាស៊ីនភ្ញៀវ និងម៉ាស៊ីនមេអនុញ្ញាត សញ្ញាសម្ងាត់ត្រូវបានបញ្ជូនក្នុងទម្រង់ដែលបានអ៊ិនគ្រីបជាមួយនឹងប៉ារ៉ាម៉ែត្រជាច្រើន និងបានផ្ទៀងផ្ទាត់នៅលើម៉ាស៊ីនមេអនុញ្ញាត។ នេះមិនមែនជាជម្រើសដ៏ងាយស្រួលបំផុតនោះទេ ដោយសារកម្មវិធីខាងក្នុងនីមួយៗត្រូវពិពណ៌នាអំពីស្រទាប់ដ៏សន្ធឹកសន្ធាប់នៃតក្កវិជ្ជា ហើយមូលដ្ឋានទិន្នន័យបុគ្គលិកត្រូវបានធ្វើសមកាលកម្មទាំងស្រុងជាមួយម៉ាស៊ីនមេអនុញ្ញាត។

បន្ទាប់ពីពេលខ្លះ យើងបានសម្រេចចិត្តសម្រួលកិច្ចការនៃការអនុញ្ញាតពីមជ្ឈិម។ SSO ត្រូវបានផ្ទេរទៅអ្នកតុល្យភាព។ ដោយមានជំនួយពី OpenResty គំរូមួយត្រូវបានបន្ថែមទៅ Lua ដែលពិនិត្យសញ្ញាសម្ងាត់ ដឹងថាកម្មវិធីណាមួយដែលសំណើនឹងទៅ ហើយអាចពិនិត្យមើលថាតើមានការចូលប្រើនៅទីនោះដែរឬទេ។ វិធីសាស្រ្តនេះបានសម្រួលយ៉ាងខ្លាំងដល់ភារកិច្ចនៃការគ្រប់គ្រងការចូលប្រើកម្មវិធីខាងក្នុង - នៅក្នុងកូដនៃកម្មវិធីនីមួយៗ វាមិនចាំបាច់ក្នុងការពណ៌នាតក្កវិជ្ជាបន្ថែមទៀតទេ។ ជាលទ្ធផល យើងបានបិទចរាចរណ៍ខាងក្រៅ ហើយកម្មវិធីខ្លួនឯងមិនបានដឹងអ្វីទាំងអស់អំពីការអនុញ្ញាត។

ទោះយ៉ាងណាក៏ដោយ បញ្ហាមួយនៅតែមិនអាចដោះស្រាយបាន។ ចុះកម្មវិធីដែលត្រូវការព័ត៌មានអំពីបុគ្គលិក? វាអាចទៅរួចក្នុងការសរសេរ API សម្រាប់សេវាកម្មអនុញ្ញាត ប៉ុន្តែបន្ទាប់មកអ្នកនឹងត្រូវបន្ថែមតក្កវិជ្ជាបន្ថែមសម្រាប់កម្មវិធីនីមួយៗ។ លើសពីនេះ យើងចង់កម្ចាត់ការពឹងផ្អែកលើកម្មវិធីដែលសរសេរដោយខ្លួនឯងមួយរបស់យើង ដែលក្រោយមកត្រូវបានបកប្រែទៅជា OpenSource នៅលើម៉ាស៊ីនមេអនុញ្ញាតខាងក្នុងរបស់យើង។ យើងនឹងនិយាយអំពីវានៅពេលផ្សេងទៀត។ OAuth បានក្លាយជាដំណោះស្រាយចំពោះបញ្ហាទាំងពីរ។

ទៅនឹងស្តង់ដារទូទៅ

OAuth គឺជាស្តង់ដារការអនុញ្ញាតដែលអាចយល់បាន ដែលត្រូវបានទទួលយកជាទូទៅ ប៉ុន្តែដោយសារតែមុខងាររបស់វាមិនទាន់គ្រប់គ្រាន់ ពួកគេបានចាប់ផ្តើមពិចារណាលើ OpenID Connect (ODC) ភ្លាមៗ។ OIDC ខ្លួនវាគឺជាការអនុវត្តទីបីនៃស្តង់ដារការផ្ទៀងផ្ទាត់បើកចំហ ដែលបានហូរចូលទៅក្នុងកម្មវិធីបន្ថែមលើពិធីការ OAuth 2.0 (ពិធីការអនុញ្ញាតបើកចំហ)។ ដំណោះស្រាយនេះបិទបញ្ហានៃកង្វះទិន្នន័យអំពីអ្នកប្រើប្រាស់ចុងក្រោយ ហើយថែមទាំងធ្វើឱ្យវាអាចផ្លាស់ប្តូរអ្នកផ្តល់ការអនុញ្ញាតផងដែរ។

ទោះជាយ៉ាងណាក៏ដោយ យើងមិនបានជ្រើសរើសអ្នកផ្តល់សេវាជាក់លាក់ណាមួយទេ ហើយបានសម្រេចចិត្តបន្ថែមការរួមបញ្ចូលជាមួយ ODC សម្រាប់ម៉ាស៊ីនមេដែលមានការអនុញ្ញាតរបស់យើង។ នៅក្នុងការពេញចិត្តនៃការសម្រេចចិត្តនេះគឺការពិតដែលថា ODC មានភាពបត់បែនខ្លាំងនៅក្នុងលក្ខខណ្ឌនៃការអនុញ្ញាតអ្នកប្រើប្រាស់ចុងក្រោយ។ ដូច្នេះ វាអាចអនុវត្តការគាំទ្រ ODC នៅលើម៉ាស៊ីនមេអនុញ្ញាតបច្ចុប្បន្នរបស់អ្នក។

វិធីរបស់យើងក្នុងការអនុវត្តម៉ាស៊ីនមេ ODC ផ្ទាល់ខ្លួនរបស់យើង។

1) នាំយកទិន្នន័យទៅទម្រង់ដែលចង់បាន

ដើម្បីរួមបញ្ចូល ODC វាចាំបាច់ក្នុងការនាំយកទិន្នន័យអ្នកប្រើប្រាស់បច្ចុប្បន្នទៅជាទម្រង់ដែលអាចយល់បានដោយស្តង់ដារ។ នៅក្នុង ODC នេះត្រូវបានគេហៅថាការទាមទារ។ ការទាមទារគឺជាវាលចុងក្រោយដ៏សំខាន់នៅក្នុងមូលដ្ឋានទិន្នន័យអ្នកប្រើប្រាស់ (ឈ្មោះ អ៊ីមែល ទូរស័ព្ទ។ល។)។ មាន បញ្ជីស្តង់ដារនៃត្រាហើយអ្វីគ្រប់យ៉ាងដែលមិនត្រូវបានបញ្ចូលក្នុងបញ្ជីនេះត្រូវបានចាត់ទុកថាជាទម្លាប់។ ដូច្នេះហើយ ចំណុចដំបូងដែលអ្នកត្រូវយកចិត្តទុកដាក់ប្រសិនបើអ្នកចង់ជ្រើសរើសអ្នកផ្តល់សេវា ODC ដែលមានស្រាប់គឺលទ្ធភាពនៃការប្តូរម៉ាកយីហោថ្មីៗយ៉ាងងាយស្រួល។

ក្រុមនៃសញ្ញាសម្គាល់ត្រូវបានបញ្ចូលគ្នាទៅក្នុងសំណុំរងខាងក្រោម - វិសាលភាព។ ក្នុងអំឡុងពេលអនុញ្ញាត ការចូលប្រើគឺមិនត្រូវបានស្នើសុំចំពោះម៉ាកជាក់លាក់ណាមួយឡើយ ប៉ុន្តែចំពោះវិសាលភាព បើទោះបីជាម៉ាកមួយចំនួនពីវិសាលភាពមិនត្រូវការក៏ដោយ។

2) អនុវត្តជំនួយចាំបាច់

ផ្នែកបន្ទាប់នៃសមាហរណកម្ម ODC គឺការជ្រើសរើស និងការអនុវត្តប្រភេទការអនុញ្ញាត ដែលហៅថាជំនួយ។ សេណារីយ៉ូបន្ថែមទៀតនៃអន្តរកម្មរវាងកម្មវិធីដែលបានជ្រើសរើស និងម៉ាស៊ីនមេអនុញ្ញាតនឹងអាស្រ័យលើជំនួយដែលបានជ្រើសរើស។ គ្រោងការណ៍គំរូសម្រាប់ការជ្រើសរើសជំនួយដែលត្រឹមត្រូវត្រូវបានបង្ហាញនៅក្នុងរូបភាពខាងក្រោម។

សម្រាប់​កម្មវិធី​ដំបូង​របស់​យើង យើង​បាន​ប្រើ​ជំនួយ​ទូទៅ​បំផុត​គឺ​កូដ​អនុញ្ញាត។ ភាពខុសគ្នារបស់វាពីអ្នកដទៃគឺថាវាជាបីជំហាន i.e. កំពុងឆ្លងកាត់ការធ្វើតេស្តបន្ថែម។ ដំបូង អ្នកប្រើប្រាស់ធ្វើការស្នើសុំការអនុញ្ញាតការអនុញ្ញាត ទទួលបានសញ្ញាសម្ងាត់ - លេខកូដអនុញ្ញាត បន្ទាប់មកជាមួយនឹងសញ្ញាសម្ងាត់នេះ ដូចជាប្រសិនបើមានសំបុត្រសម្រាប់ការធ្វើដំណើរ ស្នើសុំនិមិត្តសញ្ញាចូលដំណើរការ។ អន្តរកម្មសំខាន់ទាំងអស់នៃស្គ្រីបអនុញ្ញាតនេះគឺផ្អែកលើការបញ្ជូនបន្តរវាងកម្មវិធី និងម៉ាស៊ីនមេផ្តល់សិទ្ធិ។ អ្នកអាចអានបន្ថែមអំពីជំនួយនេះ។ នៅទីនេះ.

OAuth ប្រកាន់ខ្ជាប់នូវគោលគំនិតដែលថាសញ្ញាចូលប្រើដែលទទួលបានបន្ទាប់ពីការអនុញ្ញាតគួរតែជាបណ្តោះអាសន្ន ហើយគួរតែផ្លាស់ប្តូរ ជារៀងរាល់ 10 នាទីជាមធ្យម។ ការផ្តល់លេខកូដអនុញ្ញាតគឺជាការផ្ទៀងផ្ទាត់បីជំហានតាមរយៈការបញ្ជូនបន្ត រៀងរាល់ 10 នាទីម្តង ដើម្បីបង្វែរជំហានបែបនេះ និយាយដោយត្រង់ទៅ មិនមែនជាកិច្ចការដ៏រីករាយបំផុតសម្រាប់ភ្នែកនោះទេ។ ដើម្បីដោះស្រាយបញ្ហានេះ មានជំនួយមួយទៀតគឺ Refresh Token ដែលយើងធ្លាប់ប្រើនៅក្នុងប្រទេសរបស់យើងផងដែរ។ អ្វីៗគឺងាយស្រួលជាងនៅទីនេះ។ ក្នុងអំឡុងពេលផ្ទៀងផ្ទាត់ពីការផ្តល់ជំនួយមួយផ្សេងទៀត បន្ថែមពីលើសញ្ញាសម្ងាត់ចូលប្រើសំខាន់ មួយផ្សេងទៀតត្រូវបានចេញ - ធ្វើឱ្យស្រស់ថូខឹនដែលអាចប្រើបានតែម្តងគត់ ហើយអាយុកាលរបស់វាជាធម្មតាយូរជាងនេះ។ ជាមួយនឹង Refresh Token នេះ នៅពេលដែល TTL (Time to Live) នៃ token ចូលដំណើរការសំខាន់បញ្ចប់ សំណើរសុំសញ្ញាសម្ងាត់ចូលប្រើថ្មីនឹងមកដល់ចំណុចបញ្ចប់នៃជំនួយផ្សេងទៀត។ និមិត្តសញ្ញាធ្វើឱ្យស្រស់ដែលបានប្រើត្រូវបានកំណត់ឡើងវិញភ្លាមៗទៅសូន្យ។ ការត្រួតពិនិត្យនេះគឺមានពីរជំហាន ហើយអាចត្រូវបានអនុវត្តនៅក្នុងផ្ទៃខាងក្រោយដោយមិនអាចយល់បានចំពោះអ្នកប្រើប្រាស់។

3) រៀបចំទ្រង់ទ្រាយលទ្ធផលទិន្នន័យផ្ទាល់ខ្លួន

បន្ទាប់ពីជំនួយដែលបានជ្រើសរើសត្រូវបានអនុវត្ត ការអនុញ្ញាតដំណើរការ វាមានតម្លៃនិយាយអំពីការទទួលបានទិន្នន័យអំពីអ្នកប្រើប្រាស់ចុងក្រោយ។ ODC មានចំណុចបញ្ចប់ដាច់ដោយឡែកសម្រាប់បញ្ហានេះ ដែលអ្នកអាចស្នើសុំទិន្នន័យអ្នកប្រើប្រាស់ជាមួយនឹងសញ្ញាសម្ងាត់ចូលប្រើបច្ចុប្បន្នរបស់អ្នក ហើយប្រសិនបើវាទាន់សម័យ។ ហើយប្រសិនបើទិន្នន័យរបស់អ្នកប្រើមិនផ្លាស់ប្តូរញឹកញាប់ទេ ហើយអ្នកត្រូវធ្វើតាមព័ត៌មានបច្ចុប្បន្នជាច្រើនដង អ្នកអាចមករកដំណោះស្រាយដូចជា JWT tokens។ និមិត្តសញ្ញាទាំងនេះក៏ត្រូវបានគាំទ្រដោយស្តង់ដារផងដែរ។ និមិត្តសញ្ញា JWT ខ្លួនវាមានបីផ្នែក៖ បឋមកថា (ព័ត៌មានអំពីសញ្ញាសម្ងាត់) បន្ទុក (ទិន្នន័យចាំបាច់ណាមួយ) និងហត្ថលេខា (ហត្ថលេខា សញ្ញាសម្ងាត់ត្រូវបានចុះហត្ថលេខាដោយម៉ាស៊ីនមេ ហើយអ្នកអាចពិនិត្យមើលប្រភពនៃហត្ថលេខារបស់វានៅពេលក្រោយ) ។

នៅក្នុងការអនុវត្ត ODC និមិត្តសញ្ញា JWT ត្រូវបានគេហៅថា id_token ។ វាអាចត្រូវបានស្នើសុំរួមជាមួយនឹងនិមិត្តសញ្ញាចូលប្រើធម្មតា ហើយអ្វីដែលនៅសេសសល់គឺដើម្បីផ្ទៀងផ្ទាត់ហត្ថលេខា។ ម៉ាស៊ីនមេផ្តល់ការអនុញ្ញាតមានចំណុចបញ្ចប់ដាច់ដោយឡែកសម្រាប់វាជាមួយនឹងសោសាធារណៈជាច្រើននៅក្នុងទម្រង់ J.W.K.. ហើយ​ការ​និយាយ​ពី​ចំណុច​នេះ វា​គួរ​ឱ្យ​កត់​សម្គាល់​ថា មាន​ចំណុច​បញ្ចប់​មួយ​ទៀត​ដែល​ផ្អែក​លើ​ស្តង់ដារ RFC5785 ឆ្លុះបញ្ចាំងពីការកំណត់រចនាសម្ព័ន្ធបច្ចុប្បន្ននៃម៉ាស៊ីនមេ ODC ។ វាមានអាសយដ្ឋានចំណុចបញ្ចប់ទាំងអស់ (រួមទាំងអាសយដ្ឋាននៃសោសាធារណៈដែលប្រើសម្រាប់ការចុះហត្ថលេខា) ម៉ាក និងវិសាលភាពដែលបានគាំទ្រ ក្បួនដោះស្រាយការអ៊ិនគ្រីបដែលបានប្រើ ជំនួយដែលបានគាំទ្រ។ល។

ឧទាហរណ៍នៅលើ 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 អ្នកអាចផ្ទេរសញ្ញាសម្គាល់ចាំបាច់ទាំងអស់ទៅកាន់ payload នៃ token និងមិនទាក់ទងម៉ាស៊ីនមេអនុញ្ញាតរាល់ពេលដើម្បីស្នើសុំទិន្នន័យអ្នកប្រើប្រាស់។ គុណវិបត្តិនៃវិធីសាស្រ្តនេះគឺថាការផ្លាស់ប្តូរទិន្នន័យអ្នកប្រើប្រាស់ពីម៉ាស៊ីនមេមិនមកភ្លាមៗទេ ប៉ុន្តែរួមជាមួយនឹងសញ្ញាសម្ងាត់ចូលប្រើថ្មី។

លទ្ធផលនៃការអនុវត្ត

ដូច្នេះបន្ទាប់ពីអនុវត្តម៉ាស៊ីនមេ ODC ផ្ទាល់ខ្លួនរបស់យើង និងកំណត់រចនាសម្ព័ន្ធការតភ្ជាប់ទៅវានៅផ្នែកកម្មវិធី យើងបានដោះស្រាយបញ្ហានៃការផ្ទេរព័ត៌មានអំពីអ្នកប្រើប្រាស់។
ដោយសារ ODC គឺជាស្តង់ដារបើកចំហ យើងមានជម្រើសក្នុងការជ្រើសរើសអ្នកផ្តល់សេវាដែលមានស្រាប់ ឬការអនុវត្តម៉ាស៊ីនមេ។ យើងបានសាកល្បង Keycloak ដែលវាមានភាពងាយស្រួលក្នុងការកំណត់រចនាសម្ព័ន្ធ បន្ទាប់ពីការដំឡើង និងផ្លាស់ប្តូរការកំណត់ការភ្ជាប់នៅលើផ្នែកកម្មវិធី វារួចរាល់ក្នុងការដំណើរការ។ នៅផ្នែកខាងកម្មវិធី អ្វីដែលនៅសេសសល់គឺត្រូវផ្លាស់ប្តូរការកំណត់ការតភ្ជាប់។

និយាយអំពីដំណោះស្រាយដែលមានស្រាប់

នៅក្នុងអង្គភាពរបស់យើង ក្នុងនាមជាម៉ាស៊ីនមេ ODC ដំបូង យើងបានប្រមូលផ្តុំការអនុវត្តផ្ទាល់របស់យើង ដែលត្រូវបានបំពេញបន្ថែមតាមការចាំបាច់។ បន្ទាប់ពីការពិនិត្យឡើងវិញលម្អិតនៃដំណោះស្រាយដែលត្រៀមរួចជាស្រេចផ្សេងទៀត យើងអាចនិយាយបានថានេះគឺជាចំណុចរសើប។ នៅក្នុងការពេញចិត្តនៃការសម្រេចចិត្តក្នុងការអនុវត្តម៉ាស៊ីនមេរបស់ពួកគេ មានការព្រួយបារម្ភចំពោះផ្នែកនៃអ្នកផ្តល់សេវាក្នុងករណីដែលមិនមានមុខងារចាំបាច់ ក៏ដូចជាវត្តមាននៃប្រព័ន្ធចាស់ដែលមានការអនុញ្ញាតផ្ទាល់ខ្លួនខុសៗគ្នាសម្រាប់សេវាកម្មមួយចំនួន និងច្រើនណាស់។ ទិន្នន័យអំពីបុគ្គលិកត្រូវបានរក្សាទុករួចហើយ។ ទោះជាយ៉ាងណាក៏ដោយ នៅក្នុងការអនុវត្តដែលត្រៀមរួចជាស្រេច មានភាពងាយស្រួលក្នុងការធ្វើសមាហរណកម្ម។ ឧទាហរណ៍ Keycloak មានប្រព័ន្ធគ្រប់គ្រងអ្នកប្រើប្រាស់ផ្ទាល់ខ្លួន ហើយទិន្នន័យត្រូវបានរក្សាទុកដោយផ្ទាល់នៅក្នុងវា ហើយវានឹងមិនពិបាកក្នុងការយកឈ្នះអ្នកប្រើប្រាស់របស់អ្នកនៅទីនោះទេ។ ដើម្បីធ្វើដូចនេះ Keycloak មាន API ដែលនឹងអនុញ្ញាតឱ្យអ្នកអនុវត្តសកម្មភាពផ្ទេរចាំបាច់ទាំងអស់។

ឧទាហរណ៍មួយទៀតនៃការបញ្ជាក់ដែលគួរឱ្យចាប់អារម្មណ៍នៅក្នុងគំនិតរបស់ខ្ញុំការអនុវត្តគឺ Ory Hydra ។ វាគួរឱ្យចាប់អារម្មណ៍ព្រោះវាមានសមាសធាតុផ្សេងៗគ្នា។ ដើម្បីរួមបញ្ចូល អ្នកនឹងត្រូវភ្ជាប់សេវាកម្មគ្រប់គ្រងអ្នកប្រើប្រាស់របស់អ្នកទៅសេវាកម្មអនុញ្ញាតរបស់ពួកគេ ហើយបន្តតាមតម្រូវការ។

Keycloak និង Ory Hydra មិនមែនជាដំណោះស្រាយតែមួយគត់នោះទេ។ វាជាការល្អបំផុតក្នុងការជ្រើសរើសការអនុវត្តដែលបញ្ជាក់ដោយមូលនិធិ OpenID ។ ដំណោះស្រាយទាំងនេះជាធម្មតាមានផ្លាកសញ្ញាវិញ្ញាបនប័ត្រ OpenID ។

កុំភ្លេចអំពីអ្នកផ្តល់សេវាបង់ប្រាក់ដែលមានស្រាប់ ប្រសិនបើអ្នកមិនចង់រក្សាម៉ាស៊ីនមេ ODC របស់អ្នក។ សព្វថ្ងៃនេះមានជម្រើសល្អជាច្រើន។

មាន​អ្វី​បន្ទាប់

នាពេលអនាគតដ៏ខ្លីខាងមុខនេះ យើងនឹងបិទចរាចរណ៍ទៅកាន់សេវាកម្មខាងក្នុងតាមរបៀបផ្សេង។ យើងមានគម្រោងផ្ទេរ SSO បច្ចុប្បន្នរបស់យើងនៅលើសមតុល្យដោយប្រើ OpenResty ទៅប្រូកស៊ីដោយផ្អែកលើ OAuth ។ មានដំណោះស្រាយដែលត្រៀមរួចជាស្រេចជាច្រើននៅទីនេះ ឧទាហរណ៍៖
github.com/bitly/oauth2_proxy
github.com/ory/oathkeeper
github.com/keycloak/keycloak-gatekeeper

សំភារៈបន្ថែម

jwt.io - សេវាកម្មល្អសម្រាប់ការផ្ទៀងផ្ទាត់និមិត្តសញ្ញា JWT
openid.net/developers/certified - បញ្ជីនៃការអនុវត្ត ODC ដែលបានបញ្ជាក់

ប្រភព: www.habr.com