ഓപ്പൺഐഡി കണക്ട്: കസ്റ്റം മുതൽ സ്റ്റാൻഡേർഡ് വരെയുള്ള ആന്തരിക ആപ്ലിക്കേഷനുകളുടെ അംഗീകാരം

ഏതാനും മാസങ്ങൾക്ക് മുമ്പ്, ഞങ്ങളുടെ നൂറുകണക്കിന് ആന്തരിക ആപ്ലിക്കേഷനുകൾക്കുള്ള ആക്‌സസ് മാനേജ് ചെയ്യുന്നതിനായി ഞാൻ ഒരു OpenID കണക്റ്റ് സെർവർ നടപ്പിലാക്കുകയായിരുന്നു. ഞങ്ങളുടെ സ്വന്തം സംഭവവികാസങ്ങളിൽ നിന്ന്, ചെറിയ തോതിൽ സൗകര്യപ്രദമായ, ഞങ്ങൾ പൊതുവായി അംഗീകരിക്കപ്പെട്ട ഒരു നിലവാരത്തിലേക്ക് നീങ്ങി. കേന്ദ്ര സേവനത്തിലൂടെയുള്ള ആക്‌സസ് ഏകതാനമായ പ്രവർത്തനങ്ങളെ വളരെയധികം ലളിതമാക്കുന്നു, അംഗീകാരങ്ങൾ നടപ്പിലാക്കുന്നതിനുള്ള ചെലവ് കുറയ്ക്കുന്നു, നിരവധി റെഡിമെയ്ഡ് സൊല്യൂഷനുകൾ കണ്ടെത്താൻ നിങ്ങളെ അനുവദിക്കുന്നു, പുതിയവ വികസിപ്പിക്കുമ്പോൾ നിങ്ങളുടെ മസ്തിഷ്കത്തെ തകർക്കരുത്. ഈ ലേഖനത്തിൽ, ഈ പരിവർത്തനത്തെക്കുറിച്ചും ഞങ്ങൾക്ക് പൂരിപ്പിക്കാൻ കഴിഞ്ഞ ബമ്പുകളെക്കുറിച്ചും ഞാൻ സംസാരിക്കും.

വളരെക്കാലം മുമ്പ് ... എല്ലാം എങ്ങനെ ആരംഭിച്ചു

കുറച്ച് വർഷങ്ങൾക്ക് മുമ്പ്, മാനുവൽ നിയന്ത്രണത്തിനായി വളരെയധികം ആന്തരിക ആപ്ലിക്കേഷനുകൾ ഉണ്ടായിരുന്നപ്പോൾ, കമ്പനിക്കുള്ളിലെ ആക്സസ് നിയന്ത്രിക്കുന്നതിന് ഞങ്ങൾ ഒരു ആപ്ലിക്കേഷൻ എഴുതി. വിവിധ പ്രവർത്തനങ്ങളിലേക്കുള്ള ആക്‌സസ് കോൺഫിഗർ ചെയ്‌തിരിക്കുന്ന ജീവനക്കാരെക്കുറിച്ചുള്ള വിവരങ്ങളുള്ള ഒരു ഡാറ്റാബേസിലേക്ക് കണക്റ്റുചെയ്‌ത ഒരു ലളിതമായ റെയിൽസ് ആപ്ലിക്കേഷനായിരുന്നു ഇത്. അതേ സമയം, ഞങ്ങൾ ആദ്യത്തെ SSO ഉയർത്തി, അത് ക്ലയന്റിന്റെയും അംഗീകാര സെർവറിന്റെയും വശത്ത് നിന്നുള്ള ടോക്കണുകളുടെ സ്ഥിരീകരണത്തെ അടിസ്ഥാനമാക്കിയുള്ളതാണ്, ടോക്കൺ നിരവധി പാരാമീറ്ററുകൾ ഉപയോഗിച്ച് എൻക്രിപ്റ്റ് ചെയ്ത രൂപത്തിൽ കൈമാറുകയും അംഗീകാര സെർവറിൽ പരിശോധിച്ചുറപ്പിക്കുകയും ചെയ്തു. ഇത് ഏറ്റവും സൗകര്യപ്രദമായ ഓപ്ഷനായിരുന്നില്ല, കാരണം ഓരോ ആന്തരിക ആപ്ലിക്കേഷനും യുക്തിയുടെ ഗണ്യമായ പാളി വിവരിക്കേണ്ടതുണ്ട്, കൂടാതെ ജീവനക്കാരുടെ ഡാറ്റാബേസുകൾ അംഗീകൃത സെർവറുമായി പൂർണ്ണമായും സമന്വയിപ്പിച്ചിരിക്കുന്നു.

കുറച്ച് സമയത്തിന് ശേഷം, കേന്ദ്രീകൃത അംഗീകാരത്തിന്റെ ചുമതല ലളിതമാക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു. എസ്എസ്ഒ ബാലൻസറിലേക്ക് മാറ്റി. ഓപ്പൺ റെസ്റ്റിയുടെ സഹായത്തോടെ, ടോക്കണുകൾ പരിശോധിച്ച് ഏത് ആപ്ലിക്കേഷനിലേക്കാണ് അഭ്യർത്ഥന പോകുന്നതെന്ന് അറിയാവുന്ന ഒരു ടെംപ്ലേറ്റ് ലുവയിലേക്ക് ചേർത്തു, അവിടെ ആക്സസ് ഉണ്ടോ എന്ന് പരിശോധിക്കാം. ഈ സമീപനം ആന്തരിക ആപ്ലിക്കേഷനുകളിലേക്കുള്ള ആക്സസ് നിയന്ത്രിക്കുന്നതിനുള്ള ചുമതല വളരെ ലളിതമാക്കി - ഓരോ ആപ്ലിക്കേഷന്റെയും കോഡിൽ, അധിക ലോജിക് വിവരിക്കേണ്ട ആവശ്യമില്ല. തൽഫലമായി, ഞങ്ങൾ ട്രാഫിക്ക് ബാഹ്യമായി അടച്ചു, കൂടാതെ അപ്ലിക്കേഷന് തന്നെ അംഗീകാരത്തെക്കുറിച്ച് ഒന്നും അറിയില്ല.

എന്നിരുന്നാലും, ഒരു പ്രശ്നം പരിഹരിക്കപ്പെടാതെ തുടർന്നു. ജീവനക്കാരെ കുറിച്ചുള്ള വിവരങ്ങൾ ആവശ്യമുള്ള ആപ്ലിക്കേഷനുകളെക്കുറിച്ച്? അംഗീകാര സേവനത്തിനായി ഒരു API എഴുതാൻ സാധിച്ചു, എന്നാൽ അത്തരം ഓരോ ആപ്ലിക്കേഷനും നിങ്ങൾ കൂടുതൽ ലോജിക് ചേർക്കേണ്ടതുണ്ട്. കൂടാതെ, ഭാവിയിൽ ഓപ്പൺ സോഴ്‌സിലേക്ക് വിവർത്തനം ചെയ്യുന്നതിനായി, ഞങ്ങളുടെ ആന്തരിക അംഗീകാര സെർവറിൽ സ്വയം എഴുതിയ ആപ്ലിക്കേഷനുകളിലൊന്നിനെ ആശ്രയിക്കുന്നതിൽ നിന്ന് രക്ഷപ്പെടാൻ ഞങ്ങൾ ആഗ്രഹിച്ചു. ഞങ്ങൾ അതിനെക്കുറിച്ച് മറ്റൊരിക്കൽ സംസാരിക്കും. രണ്ട് പ്രശ്നങ്ങൾക്കും പരിഹാരം OAuth ആയിരുന്നു.

സാധാരണ നിലവാരത്തിലേക്ക്

OAuth എന്നത് മനസ്സിലാക്കാവുന്നതും പൊതുവായി അംഗീകരിക്കപ്പെട്ടതുമായ ഒരു അംഗീകാര സ്റ്റാൻഡേർഡാണ്, എന്നാൽ അതിന്റെ പ്രവർത്തനം മാത്രം മതിയാകാത്തതിനാൽ, അവർ ഉടൻ തന്നെ OpenID കണക്ട് (OIDC) പരിഗണിക്കാൻ തുടങ്ങി. OIDC തന്നെ ഓപ്പൺ ഓതന്റിക്കേഷൻ സ്റ്റാൻഡേർഡിന്റെ മൂന്നാമത്തെ നിർവ്വഹണമാണ്, ഇത് OAuth 2.0 പ്രോട്ടോക്കോളിന് (ഒരു ഓപ്പൺ ഓതറൈസേഷൻ പ്രോട്ടോക്കോൾ) മേൽ ഒരു ആഡ്-ഓണിലേക്ക് ഒഴുകുന്നു. ഈ പരിഹാരം അന്തിമ ഉപയോക്താവിനെക്കുറിച്ചുള്ള ഡാറ്റയുടെ അഭാവത്തിന്റെ പ്രശ്നം അടയ്ക്കുന്നു, കൂടാതെ അംഗീകാര ദാതാവിനെ മാറ്റുന്നതും സാധ്യമാക്കുന്നു.

എന്നിരുന്നാലും, ഞങ്ങൾ ഒരു നിർദ്ദിഷ്‌ട ദാതാവിനെ തിരഞ്ഞെടുത്തില്ല, ഞങ്ങളുടെ നിലവിലുള്ള അംഗീകാര സെർവറിനായി OIDC-യുമായി സംയോജനം ചേർക്കാൻ തീരുമാനിച്ചു. അന്തിമ ഉപയോക്തൃ അംഗീകാരത്തിന്റെ കാര്യത്തിൽ OIDC വളരെ വഴക്കമുള്ളതാണ് എന്ന വസ്തുത ഈ തീരുമാനത്തിന് അനുകൂലമായിരുന്നു. അതിനാൽ, നിങ്ങളുടെ നിലവിലെ അംഗീകാര സെർവറിൽ OIDC പിന്തുണ നടപ്പിലാക്കാൻ സാധിച്ചു.

ഞങ്ങളുടെ സ്വന്തം OIDC സെർവർ നടപ്പിലാക്കുന്നതിനുള്ള ഞങ്ങളുടെ രീതി

1) ആവശ്യമുള്ള ഫോമിലേക്ക് ഡാറ്റ കൊണ്ടുവന്നു

OIDC സംയോജിപ്പിക്കുന്നതിന്, നിലവിലെ ഉപയോക്തൃ ഡാറ്റ സ്റ്റാൻഡേർഡ് അനുസരിച്ച് മനസ്സിലാക്കാവുന്ന ഒരു ഫോമിലേക്ക് കൊണ്ടുവരേണ്ടത് ആവശ്യമാണ്. OIDC-യിൽ ഇതിനെ ക്ലെയിംസ് എന്ന് വിളിക്കുന്നു. ക്ലെയിമുകൾ പ്രധാനമായും ഉപയോക്തൃ ഡാറ്റാബേസിലെ (പേര്, ഇമെയിൽ, ഫോൺ മുതലായവ) അന്തിമ ഫീൽഡുകളാണ്. നിലവിലുണ്ട് സ്റ്റാമ്പുകളുടെ സ്റ്റാൻഡേർഡ് ലിസ്റ്റ്, കൂടാതെ ഈ ലിസ്റ്റിൽ ഉൾപ്പെടാത്തതെല്ലാം ഇഷ്‌ടാനുസൃതമായി കണക്കാക്കുന്നു. അതിനാൽ, നിലവിലുള്ള ഒരു OIDC ദാതാവിനെ തിരഞ്ഞെടുക്കണമെങ്കിൽ നിങ്ങൾ ശ്രദ്ധിക്കേണ്ട ആദ്യ പോയിന്റ് പുതിയ ബ്രാൻഡുകളുടെ സൗകര്യപ്രദമായ ഇഷ്‌ടാനുസൃതമാക്കാനുള്ള സാധ്യതയാണ്.

ഹാൾമാർക്കുകളുടെ ഗ്രൂപ്പ് ഇനിപ്പറയുന്ന ഉപസെറ്റിലേക്ക് സംയോജിപ്പിച്ചിരിക്കുന്നു - സ്കോപ്പ്. അംഗീകാര സമയത്ത്, നിർദ്ദിഷ്ട ബ്രാൻഡുകളിലേക്കല്ല, സ്കോപ്പുകളിലേക്കാണ് ആക്സസ് അഭ്യർത്ഥിക്കുന്നത്, സ്കോപ്പിൽ നിന്നുള്ള ചില ബ്രാൻഡുകൾ ആവശ്യമില്ലെങ്കിലും.

2) ആവശ്യമായ ഗ്രാന്റുകൾ നടപ്പിലാക്കി

ഒഐഡിസി സംയോജനത്തിന്റെ അടുത്ത ഭാഗം ഗ്രാന്റുകൾ എന്ന് വിളിക്കപ്പെടുന്ന അംഗീകാര തരങ്ങളുടെ തിരഞ്ഞെടുപ്പും നടപ്പാക്കലുമാണ്. തിരഞ്ഞെടുത്ത ആപ്ലിക്കേഷനും അംഗീകാര സെർവറും തമ്മിലുള്ള ആശയവിനിമയത്തിന്റെ കൂടുതൽ സാഹചര്യം തിരഞ്ഞെടുത്ത ഗ്രാന്റിനെ ആശ്രയിച്ചിരിക്കും. ശരിയായ ഗ്രാന്റ് തിരഞ്ഞെടുക്കുന്നതിനുള്ള ഒരു മാതൃകാപരമായ സ്കീം ചുവടെയുള്ള ചിത്രത്തിൽ കാണിച്ചിരിക്കുന്നു.

ഞങ്ങളുടെ ആദ്യ ആപ്ലിക്കേഷനായി, ഞങ്ങൾ ഏറ്റവും സാധാരണമായ ഗ്രാന്റ്, ഓതറൈസേഷൻ കോഡ് ഉപയോഗിച്ചു. മറ്റുള്ളവയിൽ നിന്നുള്ള വ്യത്യാസം അത് മൂന്ന്-ഘട്ടമാണ്, അതായത്. അധിക പരിശോധനയ്ക്ക് വിധേയമാണ്. ആദ്യം, ഉപയോക്താവ് അംഗീകാര അനുമതിക്കായി ഒരു അഭ്യർത്ഥന നടത്തുന്നു, ഒരു ടോക്കൺ - ഓതറൈസേഷൻ കോഡ് സ്വീകരിക്കുന്നു, തുടർന്ന് ഈ ടോക്കൺ ഉപയോഗിച്ച്, യാത്രയ്ക്കുള്ള ടിക്കറ്റ് പോലെ, ഒരു ആക്സസ് ടോക്കൺ അഭ്യർത്ഥിക്കുന്നു. ഈ അംഗീകാര സ്ക്രിപ്റ്റിന്റെ എല്ലാ പ്രധാന ഇടപെടലുകളും ആപ്ലിക്കേഷനും അംഗീകാര സെർവറും തമ്മിലുള്ള റീഡയറക്‌ടുകളെ അടിസ്ഥാനമാക്കിയുള്ളതാണ്. ഈ ഗ്രാന്റിനെക്കുറിച്ച് നിങ്ങൾക്ക് കൂടുതൽ വായിക്കാം ഇവിടെ.

അംഗീകാരത്തിന് ശേഷം ലഭിക്കുന്ന ആക്‌സസ് ടോക്കണുകൾ താൽക്കാലികവും ശരാശരി ഓരോ 10 മിനിറ്റിലും മാറുന്നതുമായ ആശയം OAuth പാലിക്കുന്നു. ഓതറൈസേഷൻ കോഡ് ഗ്രാന്റ് എന്നത് റീഡയറക്‌ടിലൂടെയുള്ള മൂന്ന്-ഘട്ട പരിശോധനയാണ്, ഓരോ 10 മിനിറ്റിലും അത്തരമൊരു ഘട്ടം തിരിയുക, തുറന്നുപറയുക, കണ്ണുകൾക്ക് ഏറ്റവും മനോഹരമായ ജോലിയല്ല. ഈ പ്രശ്നം പരിഹരിക്കാൻ, മറ്റൊരു ഗ്രാന്റ് ഉണ്ട് - റീഫ്രഷ് ടോക്കൺ, അത് ഞങ്ങൾ നമ്മുടെ രാജ്യത്തും ഉപയോഗിച്ചു. ഇവിടെ എല്ലാം എളുപ്പമാണ്. മറ്റൊരു ഗ്രാന്റിൽ നിന്നുള്ള സ്ഥിരീകരണ വേളയിൽ, പ്രധാന ആക്സസ് ടോക്കണിന് പുറമേ, മറ്റൊന്ന് ഇഷ്യൂ ചെയ്യുന്നു - പുതുക്കിയ ടോക്കൺ, അത് ഒരിക്കൽ മാത്രമേ ഉപയോഗിക്കാനാവൂ, അതിന്റെ ആയുസ്സ് സാധാരണയായി വളരെ കൂടുതലാണ്. ഈ പുതുക്കിയ ടോക്കൺ ഉപയോഗിച്ച്, പ്രധാന ആക്‌സസ് ടോക്കണിന്റെ TTL (ലൈവ് ടു ടൈം) അവസാനിക്കുമ്പോൾ, ഒരു പുതിയ ആക്‌സസ് ടോക്കണിനായുള്ള അഭ്യർത്ഥന മറ്റൊരു ഗ്രാന്റിന്റെ അവസാന പോയിന്റിലേക്ക് വരും. ഉപയോഗിച്ച പുതുക്കിയ ടോക്കൺ ഉടൻ പൂജ്യത്തിലേക്ക് പുനഃസജ്ജമാക്കും. ഈ പരിശോധന രണ്ട്-ഘട്ടമാണ്, ഉപയോക്താവിന് അദൃശ്യമായി പശ്ചാത്തലത്തിൽ ഇത് നടപ്പിലാക്കാൻ കഴിയും.

3) ഇഷ്‌ടാനുസൃത ഡാറ്റ ഔട്ട്പുട്ട് ഫോർമാറ്റുകൾ സജ്ജീകരിക്കുക

തിരഞ്ഞെടുത്ത ഗ്രാന്റുകൾ നടപ്പിലാക്കിയ ശേഷം, അംഗീകാരം പ്രവർത്തിക്കുന്നു, അന്തിമ ഉപയോക്താവിനെക്കുറിച്ചുള്ള ഡാറ്റ ലഭിക്കുന്നത് പരാമർശിക്കേണ്ടതാണ്. OIDC-ന് ഇതിനായി ഒരു പ്രത്യേക എൻഡ്‌പോയിന്റ് ഉണ്ട്, അവിടെ നിങ്ങളുടെ നിലവിലെ ആക്‌സസ് ടോക്കൺ ഉപയോഗിച്ച് ഉപയോക്തൃ ഡാറ്റ അഭ്യർത്ഥിക്കാം, അത് കാലികമാണെങ്കിൽ. ഉപയോക്താവിന്റെ ഡാറ്റ ഇടയ്‌ക്കിടെ മാറുന്നില്ലെങ്കിൽ, നിലവിലുള്ളവ നിങ്ങൾ പലതവണ പിന്തുടരേണ്ടതുണ്ടെങ്കിൽ, നിങ്ങൾക്ക് JWT ടോക്കണുകൾ പോലുള്ള ഒരു പരിഹാരത്തിലേക്ക് വരാം. ഈ ടോക്കണുകളും സ്റ്റാൻഡേർഡ് പിന്തുണയ്ക്കുന്നു. JWT ടോക്കണിൽ തന്നെ മൂന്ന് ഭാഗങ്ങൾ അടങ്ങിയിരിക്കുന്നു: തലക്കെട്ട് (ടോക്കണിനെക്കുറിച്ചുള്ള വിവരങ്ങൾ), പേലോഡ് (ആവശ്യമായ ഏതെങ്കിലും ഡാറ്റ), ഒപ്പ് (ഒപ്പ്, ടോക്കൺ സെർവർ ഒപ്പിട്ടതാണ്, നിങ്ങൾക്ക് പിന്നീട് അതിന്റെ ഒപ്പിന്റെ ഉറവിടം പരിശോധിക്കാം).

OIDC നടപ്പിലാക്കലിൽ, JWT ടോക്കണിനെ id_token എന്ന് വിളിക്കുന്നു. ഒരു സാധാരണ ആക്‌സസ് ടോക്കണിനൊപ്പം ഇത് അഭ്യർത്ഥിക്കാം, ഒപ്പ് പരിശോധിച്ചുറപ്പിക്കുക മാത്രമാണ് അവശേഷിക്കുന്നത്. ഫോർമാറ്റിലുള്ള ഒരു കൂട്ടം പൊതു കീകൾക്കൊപ്പം അംഗീകാര സെർവറിന് ഇതിനായി ഒരു പ്രത്യേക എൻഡ് പോയിന്റ് ഉണ്ട് ജെ.ഡബ്ല്യു.കെ.. ഇതിനെക്കുറിച്ച് പറയുമ്പോൾ, സ്റ്റാൻഡേർഡിനെ അടിസ്ഥാനമാക്കിയുള്ള മറ്റൊരു അവസാന പോയിന്റ് ഉണ്ടെന്ന് പരാമർശിക്കേണ്ടതാണ് 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 ഒരു ഓപ്പൺ സ്റ്റാൻഡേർഡ് ആയതിനാൽ, നിലവിലുള്ള ഒരു ദാതാവിനെയോ സെർവർ നടപ്പിലാക്കുന്നതിനെയോ തിരഞ്ഞെടുക്കാനുള്ള ഓപ്‌ഷൻ ഞങ്ങൾക്ക് ഉണ്ട്. ഞങ്ങൾ കീക്ലോക്ക് പരീക്ഷിച്ചു, അത് കോൺഫിഗർ ചെയ്യാൻ വളരെ സൗകര്യപ്രദമായി മാറി, ആപ്ലിക്കേഷൻ ഭാഗത്ത് കണക്ഷൻ കോൺഫിഗറേഷനുകൾ സജ്ജീകരിക്കുകയും മാറ്റുകയും ചെയ്ത ശേഷം, അത് പോകാൻ തയ്യാറാണ്. ആപ്ലിക്കേഷന്റെ ഭാഗത്ത്, കണക്ഷൻ കോൺഫിഗറേഷനുകൾ മാറ്റുക മാത്രമാണ് അവശേഷിക്കുന്നത്.

നിലവിലുള്ള പരിഹാരങ്ങളെക്കുറിച്ച് സംസാരിക്കുന്നു

ഞങ്ങളുടെ ഓർഗനൈസേഷനിൽ, ആദ്യത്തെ OIDC സെർവർ എന്ന നിലയിൽ, ഞങ്ങളുടെ സ്വന്തം നടപ്പാക്കൽ ഞങ്ങൾ സമാഹരിച്ചു, അത് ആവശ്യാനുസരണം അനുബന്ധമായി നൽകി. മറ്റ് റെഡിമെയ്ഡ് പരിഹാരങ്ങളുടെ വിശദമായ അവലോകനത്തിന് ശേഷം, ഇത് ഒരു പ്രധാന പോയിന്റാണെന്ന് നമുക്ക് പറയാം. സ്വന്തം സെർവർ നടപ്പിലാക്കാനുള്ള തീരുമാനത്തിന് അനുകൂലമായി, ആവശ്യമായ പ്രവർത്തനങ്ങളുടെ അഭാവത്തിൽ ദാതാക്കളുടെ ഭാഗത്ത് ആശങ്കകൾ ഉണ്ടായിരുന്നു, അതുപോലെ തന്നെ ചില സേവനങ്ങൾക്ക് വ്യത്യസ്ത ഇഷ്‌ടാനുസൃത അംഗീകാരങ്ങളുള്ള ഒരു പഴയ സിസ്റ്റത്തിന്റെ സാന്നിധ്യവും ധാരാളം. ജീവനക്കാരെക്കുറിച്ചുള്ള വിവരങ്ങൾ ഇതിനകം സംഭരിച്ചിട്ടുണ്ട്. എന്നിരുന്നാലും, റെഡിമെയ്ഡ് നടപ്പാക്കലുകളിൽ, സംയോജനത്തിനുള്ള സൗകര്യങ്ങളുണ്ട്. ഉദാഹരണത്തിന്, Keycloak-ന് അതിന്റേതായ ഉപയോക്തൃ മാനേജുമെന്റ് സിസ്റ്റം ഉണ്ട്, ഡാറ്റ അതിൽ നേരിട്ട് സംഭരിച്ചിരിക്കുന്നു, നിങ്ങളുടെ ഉപയോക്താക്കളെ അവിടെ മറികടക്കുന്നത് ബുദ്ധിമുട്ടുള്ള കാര്യമല്ല. ഇത് ചെയ്യുന്നതിന്, ആവശ്യമായ എല്ലാ കൈമാറ്റ പ്രവർത്തനങ്ങളും പൂർണ്ണമായി നടപ്പിലാക്കാൻ നിങ്ങളെ അനുവദിക്കുന്ന ഒരു API കീക്ലോക്കിന് ഉണ്ട്.

ഒരു സർട്ടിഫൈഡ്, രസകരമായ, എന്റെ അഭിപ്രായത്തിൽ, നടപ്പാക്കലിന്റെ മറ്റൊരു ഉദാഹരണം Ory Hydra ആണ്. വ്യത്യസ്ത ഘടകങ്ങൾ അടങ്ങിയിരിക്കുന്നതിനാൽ ഇത് രസകരമാണ്. സംയോജിപ്പിക്കുന്നതിന്, നിങ്ങളുടെ ഉപയോക്തൃ മാനേജുമെന്റ് സേവനത്തെ അവരുടെ അംഗീകാര സേവനവുമായി ലിങ്ക് ചെയ്യുകയും ആവശ്യാനുസരണം നീട്ടുകയും ചെയ്യേണ്ടതുണ്ട്.

കീക്ലോക്കും ഓറി ഹൈഡ്രയും മാത്രമല്ല ഓഫ്-ദി-ഷെൽഫ് പരിഹാരങ്ങൾ. OpenID ഫൗണ്ടേഷൻ സാക്ഷ്യപ്പെടുത്തിയ ഒരു നടപ്പിലാക്കൽ തിരഞ്ഞെടുക്കുന്നതാണ് നല്ലത്. ഈ പരിഹാരങ്ങൾക്ക് സാധാരണയായി ഒരു ഓപ്പൺഐഡി സർട്ടിഫിക്കേഷൻ ബാഡ്ജ് ഉണ്ടായിരിക്കും.

നിങ്ങളുടെ OIDC സെർവർ നിലനിർത്താൻ താൽപ്പര്യമില്ലെങ്കിൽ നിലവിലുള്ള പണമടച്ചുള്ള ദാതാക്കളെ കുറിച്ച് മറക്കരുത്. ഇന്ന് ധാരാളം നല്ല ഓപ്ഷനുകൾ ഉണ്ട്.

അടുത്തത് എന്താണ്

സമീപഭാവിയിൽ, ഞങ്ങൾ മറ്റൊരു രീതിയിൽ ആന്തരിക സേവനങ്ങളിലേക്കുള്ള ട്രാഫിക് അടയ്ക്കാൻ പോകുന്നു. OAuth അടിസ്ഥാനമാക്കിയുള്ള ഒരു പ്രോക്സിയിലേക്ക് OpenResty ഉപയോഗിച്ച് ബാലൻസറിൽ ഞങ്ങളുടെ നിലവിലെ SSO കൈമാറാൻ ഞങ്ങൾ പദ്ധതിയിടുന്നു. ഇവിടെ ഇതിനകം തന്നെ നിരവധി റെഡിമെയ്ഡ് പരിഹാരങ്ങളുണ്ട്, ഉദാഹരണത്തിന്:
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