ከጥቂት ወራት በፊት፣ በመቶዎች ለሚቆጠሩ የውስጥ መተግበሪያዎቻችን መዳረሻን ለማስተዳደር የOpenID Connect አገልጋይን ተግባራዊ እያደረግሁ ነበር። ከራሳችን እድገቶች በትንሽ ሚዛን ምቹ ፣ ወደ አጠቃላይ ተቀባይነት ያለው ደረጃ ተሸጋግረናል። በማዕከላዊ አገልግሎት ማግኘት ነጠላ ስራዎችን በእጅጉ ያቃልላል ፣ ፈቃዶችን የማስፈፀም ወጪን ይቀንሳል ፣ ብዙ ዝግጁ መፍትሄዎችን እንዲያገኙ እና አዳዲሶችን በሚገነቡበት ጊዜ አእምሮዎን እንዳያደናቅፉ ያስችልዎታል። በዚህ ጽሑፍ ውስጥ, ስለዚህ ሽግግር እና መሙላት ስለቻልንባቸው እብጠቶች እናገራለሁ.
ከረጅም ጊዜ በፊት ... ሁሉም እንዴት እንደጀመረ
ከጥቂት አመታት በፊት፣ ለእጅ ቁጥጥር በጣም ብዙ የውስጥ አፕሊኬሽኖች በነበሩበት ጊዜ፣ በኩባንያው ውስጥ መግባትን ለመቆጣጠር ማመልከቻ ጽፈናል። ስለ ሰራተኞች መረጃ ካለው የውሂብ ጎታ ጋር የተገናኘ ቀላል የባቡር ሀዲድ መተግበሪያ ነበር ፣ እሱም ለተለያዩ ተግባራት ተደራሽነት የተዋቀረ ነው። በተመሳሳይ ጊዜ ከደንበኛው እና ከፍቃዱ አገልጋይ በኩል ቶከኖች በማጣራት ላይ የተመሰረተውን የመጀመሪያውን SSO አነሳን, ምልክቱ በበርካታ ልኬቶች ኢንክሪፕት በሆነ መልኩ ተላልፏል እና በተፈቀደው አገልጋይ ላይ ተረጋግጧል. ይህ በጣም ምቹ አማራጭ አልነበረም፣ ምክንያቱም እያንዳንዱ የውስጥ መተግበሪያ ብዙ አመክንዮዎችን መግለጽ ስለነበረበት እና የሰራተኛው የውሂብ ጎታ ከፍቃድ አገልጋዩ ጋር ሙሉ በሙሉ የተመሳሰለ ነበር።
ከተወሰነ ጊዜ በኋላ, የተማከለ ፍቃድ ስራን ለማቃለል ወሰንን. ኤስኤስኦ ወደ ሚዛኑ ተላልፏል። በOpenResty እገዛ፣ ቶከኖችን የሚፈትሽ፣ ጥያቄው ወደየትኛው መተግበሪያ እንደሚሄድ የሚያውቅ እና እዚያ መዳረሻ መኖሩን የሚያረጋግጥ አብነት ወደ Lua ተጨምሯል። ይህ አካሄድ የውስጣዊ አፕሊኬሽኖችን መዳረሻ የመቆጣጠር ስራን በእጅጉ አቃልሎታል - በእያንዳንዱ መተግበሪያ ኮድ ውስጥ ተጨማሪ አመክንዮዎችን መግለጽ አስፈላጊ አልነበረም። በውጤቱም, ትራፊክን በውጭ ዘጋን, እና አፕሊኬሽኑ እራሱ ስለ ፍቃድ ምንም አያውቅም.
ሆኖም አንድ ችግር ሳይፈታ ቆይቷል። ስለ ሰራተኞች መረጃ ስለሚያስፈልጋቸው መተግበሪያዎችስ? ለፍቃድ አገልግሎት ኤፒአይ መፃፍ ይቻል ነበር፣ነገር ግን ለእያንዳንዱ እንደዚህ አይነት መተግበሪያ ተጨማሪ አመክንዮ ማከል አለቦት። በተጨማሪም፣ በውስጣዊ ፍቃድ አገልጋያችን ላይ ወደፊት ወደ OpenSource ለመተርጎም በተዘጋጀው በራስ-የተፃፈ መተግበሪያችን ላይ ያለውን ጥገኝነት ማስወገድ እንፈልጋለን። ስለ እሱ ሌላ ጊዜ እንነጋገራለን. የሁለቱም ችግሮች መፍትሄ OAuth ነበር።
ወደ የጋራ መመዘኛዎች
OAuth ለመረዳት የሚቻል፣ በአጠቃላይ ተቀባይነት ያለው የፈቃድ መስፈርት ነው፣ ነገር ግን ተግባራቱ ብቻ በቂ ስላልሆነ፣ ወዲያው የ OpenID Connect (OIDC)ን ማጤን ጀመሩ። OIDC ራሱ በOAuth 2.0 ፕሮቶኮል (የተከፈተ የፈቀዳ ፕሮቶኮል) ላይ ወደ ተጨማሪው የፈሰሰው ክፍት የማረጋገጫ ደረጃ ሶስተኛው ትግበራ ነው። ይህ መፍትሔ ስለ መጨረሻ ተጠቃሚው የውሂብ እጥረት ችግርን ይዘጋዋል, እና የፍቃድ ሰጪውን ለመለወጥም ያስችላል.
ነገር ግን፣ አንድ የተወሰነ አገልግሎት አቅራቢን አልመረጥንም፣ እና ለነባር የፈቃድ አገልጋያችን ከOIDC ጋር ውህደትን ለመጨመር ወስነናል። ለዚህ ውሳኔ የሚደግፈው OIDC ከዋና ተጠቃሚ ፍቃድ አንፃር በጣም ተለዋዋጭ መሆኑ ነው። ስለዚህ፣ አሁን ባለው የፈቃድ አገልጋይዎ ላይ የOIDC ድጋፍን ተግባራዊ ማድረግ ተችሏል።
የራሳችንን OIDC አገልጋይ የምንተገብርበት መንገድ
1) ውሂቡን ወደሚፈለገው ቅጽ አምጥቷል
OIDCን ለማዋሃድ አሁን ያለውን የተጠቃሚ መረጃ በደረጃው ለመረዳት በሚያስችል ቅጽ ማምጣት አስፈላጊ ነው። በOIDC ይህ የይገባኛል ጥያቄ ይባላል። የይገባኛል ጥያቄዎች በተጠቃሚ ዳታቤዝ (ስም፣ ኢሜል፣ ስልክ፣ ወዘተ) ውስጥ የመጨረሻ የመጨረሻ መስኮች ናቸው። አለ። , እና በዚህ ዝርዝር ውስጥ ያልተካተቱ ሁሉም ነገሮች እንደ ልማድ ይቆጠራሉ. ስለዚህ, አሁን ያለውን የኦአይዲሲ አገልግሎት አቅራቢን ለመምረጥ ከፈለጉ ትኩረት መስጠት ያለብዎት የመጀመሪያው ነጥብ አዲስ የምርት ስሞችን ምቹ የማበጀት እድል ነው.
የአዳራሹ ቡድን በሚከተለው ንዑስ ክፍል ውስጥ ተጣምሯል - ወሰን. በፈቃድ ጊዜ፣ መዳረሻ የሚጠየቀው ለተወሰኑ ብራንዶች አይደለም፣ ነገር ግን ወሰን፣ ምንም እንኳን ከስፋቱ የተወሰኑት የምርት ስሞች አያስፈልጉም።
2) አስፈላጊዎቹን ድጎማዎች ተግባራዊ አድርገዋል
የ OIDC ውህደት ቀጣዩ ክፍል የፍቃድ ዓይነቶችን መምረጥ እና መተግበር ነው, የገንዘብ ድጋፍ የሚባሉት. በተመረጠው መተግበሪያ እና በፈቃድ ሰጪው አገልጋይ መካከል ያለው ተጨማሪ መስተጋብር በተመረጠው ስጦታ ላይ ይወሰናል። ትክክለኛውን ስጦታ ለመምረጥ አንድ ምሳሌያዊ እቅድ ከዚህ በታች ባለው ስእል ይታያል.
ለመጀመሪያ መተግበሪያችን በጣም የተለመደውን የፍቃድ ኮድ ተጠቀምን። ከሌሎች ጋር ያለው ልዩነት ሶስት እርከን ነው, ማለትም. ተጨማሪ ምርመራ እያደረገ ነው። በመጀመሪያ, ተጠቃሚው የፍቃድ ፍቃድ ጥያቄን ያቀርባል, ምልክት ይቀበላል - የፍቃድ ኮድ, ከዚያም በዚህ ማስመሰያ, ለጉዞ ቲኬት እንዳለው, የመዳረሻ ማስመሰያ ይጠይቃል. የዚህ የፈቃድ ስክሪፕት ዋና መስተጋብር በመተግበሪያው እና በፈቃድ አገልጋዩ መካከል ባሉ አቅጣጫዎች ላይ የተመሰረተ ነው። ስለዚህ ስጦታ የበለጠ ማንበብ ይችላሉ። .
OAuth ከተፈቀደ በኋላ የተገኙት የመዳረሻ ቶከኖች ጊዜያዊ መሆን አለባቸው እና በየ10 ደቂቃው በአማካይ መቀየር አለባቸው የሚለውን ፅንሰ-ሃሳብ ያከብራል። የፈቃድ ኮድ ስጦታ በየ 10 ደቂቃው እንዲህ ዓይነቱን እርምጃ ለመዞር በማዘዋወር የሶስት ደረጃ ማረጋገጫ ነው ፣ እውነቱን ለመናገር ፣ ለዓይን በጣም አስደሳች ተግባር አይደለም። ይህንን ችግር ለመፍታት, ሌላ እርዳታ አለ - Refresh Token, እሱም በአገራችንም እንጠቀማለን. እዚህ ሁሉም ነገር ቀላል ነው. ከሌላ ዕርዳታ በማረጋገጥ ጊዜ፣ ከዋናው የመዳረሻ ቶከን በተጨማሪ፣ ሌላ ወጥቷል - Refresh Token፣ አንድ ጊዜ ብቻ ጥቅም ላይ ሊውል የሚችል እና ህይወቱ ብዙ ጊዜ ይረዝማል። በዚህ የማደስ ማስመሰያ፣ የዋናው የመዳረሻ ማስመሰያ ቲቲኤል (የመኖር ጊዜ) ሲያልቅ፣ የአዲስ መዳረሻ ማስመሰያ ጥያቄው ወደ ሌላ ስጦታ መጨረሻ ነጥብ ይመጣል። ጥቅም ላይ የዋለው የማደስ ቶከን ወዲያውኑ ወደ ዜሮ ተቀናብሯል። ይህ ቼክ ባለ ሁለት ደረጃ ነው እና ለተጠቃሚው በማይታወቅ ሁኔታ ከበስተጀርባ ሊከናወን ይችላል።
3) ብጁ የውሂብ ውፅዓት ቅርጸቶችን ያዋቅሩ
የተመረጡት ዕርዳታዎች ከተተገበሩ በኋላ ፈቀዳ ይሠራል, ስለ መጨረሻው ተጠቃሚ መረጃ ማግኘትን መጥቀስ ተገቢ ነው. OIDC ለዚህ የተለየ የመጨረሻ ነጥብ አለው፣ የተጠቃሚ ውሂብ አሁን ባለው የመዳረሻ ቶከን እና ወቅታዊ ከሆነ መጠየቅ ይችላሉ። እና የተጠቃሚው ውሂብ ብዙ ጊዜ የማይለዋወጥ ከሆነ እና የአሁኑን ብዙ ጊዜ መከተል ካለብዎት እንደ JWT ቶከኖች ወደ እንደዚህ ያለ መፍትሄ መምጣት ይችላሉ። እነዚህ ምልክቶች እንዲሁ በደረጃው የተደገፉ ናቸው። የጄደብሊውቲ ማስመሰያው ራሱ ሶስት ክፍሎችን ያቀፈ ነው፡ አርዕስት (ስለ ማስመሰያው መረጃ)፣ ክፍያ (ማንኛውም አስፈላጊ መረጃ) እና ፊርማ (ፊርማ፣ ማስመሰያው በአገልጋዩ የተፈረመ ሲሆን በኋላም የፊርማውን ምንጭ ማረጋገጥ ይችላሉ)።
በOIDC አተገባበር የJWT ቶከን id_token ይባላል። ከመደበኛ የመዳረሻ ቶከን ጋር ሊጠየቅ ይችላል እና የቀረው ፊርማውን ማረጋገጥ ብቻ ነው። የፈቃድ አገልጋዩ በቅርጸቱ ውስጥ ካሉ የህዝብ ቁልፎች ስብስብ ጋር ለዚህ የተለየ የመጨረሻ ነጥብ አለው። . እና ይህን በተመለከተ, ሌላ የመጨረሻ ነጥብ መኖሩን መጥቀስ ተገቢ ነው, እሱም በደረጃው መሰረት የአሁኑን የኦአይዲሲ አገልጋይ ውቅር ያንፀባርቃል። እሱ ሁሉንም የመጨረሻ ነጥብ አድራሻዎች (ለመፈረም ጥቅም ላይ የዋለውን የህዝብ ቁልፍ ቀለበት አድራሻን ጨምሮ) ፣ የሚደገፉ ብራንዶች እና ወሰኖች ፣ ያገለገሉ ምስጠራ ስልተ ቀመሮች ፣ የሚደገፉ ድጎማዎች ፣ ወዘተ.
ለምሳሌ በጎግል ላይ፡-
{
"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ን ሞከርን ፣ በማመልከቻው በኩል የግንኙነት ውቅሮችን ካቀናበሩ እና ከቀየሩ በኋላ ፣ ለመሄድ ዝግጁ ነው። በመተግበሪያው በኩል, የሚቀረው የግንኙነት አወቃቀሮችን መቀየር ብቻ ነው.
ስለ ነባር መፍትሄዎች ማውራት
በድርጅታችን ውስጥ እንደ መጀመሪያው የኦአይዲሲ አገልጋይ የራሳችንን አተገባበር አሰባስበናል፣ ይህም እንደ አስፈላጊነቱ ተሟልቷል። ስለ ሌሎች ዝግጁ መፍትሄዎች ዝርዝር ግምገማ ካደረግን በኋላ, ይህ የማይረባ ነጥብ ነው ማለት እንችላለን. የራሳቸውን አገልጋይ ተግባራዊ ለማድረግ ውሳኔን በመደገፍ አስፈላጊው ተግባር በሌለበት በአቅራቢዎች በኩል እንዲሁም ለአንዳንድ አገልግሎቶች የተለያዩ ብጁ ፈቃዶች እና በጣም ብዙ የድሮ ስርዓት በሌለበት ሁኔታ በአቅራቢዎች ላይ ስጋቶች ነበሩ ። የሰራተኞች መረጃ አስቀድሞ ተከማችቷል። ነገር ግን, በተዘጋጁ አተገባበር ውስጥ, ለመዋሃድ ምቹ ሁኔታዎች አሉ. ለምሳሌ ኪይክሎክ የራሱ የተጠቃሚ አስተዳደር ስርዓት አለው እና ውሂቡ በቀጥታ በውስጡ ይከማቻል እና ተጠቃሚዎችዎን እዚያ ለመድረስ አስቸጋሪ አይሆንም። ይህንን ለማድረግ, Keycloak ሁሉንም አስፈላጊ የማስተላለፊያ እርምጃዎችን ሙሉ በሙሉ ለማከናወን የሚያስችል ኤፒአይ አለው.
ሌላው የተረጋገጠ፣ አስደሳች፣ በእኔ አስተያየት ትግበራ ኦሪ ሃይድራ ምሳሌ ነው። የሚስብ ነው, ምክንያቱም የተለያዩ ክፍሎችን ያቀፈ ነው. ለማዋሃድ የተጠቃሚ አስተዳደር አገልግሎትዎን ከፍቃድ አገልግሎታቸው ጋር ማገናኘት እና እንደ አስፈላጊነቱ ማራዘም ያስፈልግዎታል።
Keycloak እና Ory Hydra ከመደርደሪያው ውጪ ብቸኛ መፍትሄዎች አይደሉም። በ OpenID ፋውንዴሽን የተረጋገጠ ትግበራ መምረጥ የተሻለ ነው. እነዚህ መፍትሄዎች ብዙውን ጊዜ የክፍት መታወቂያ ማረጋገጫ ባጅ አላቸው።
እንዲሁም የእርስዎን OIDC አገልጋይ ማቆየት ካልፈለጉ ስለነባር የሚከፈልባቸው አቅራቢዎች አይርሱ። ዛሬ ብዙ ጥሩ አማራጮች አሉ.
የሚቀጥለው ምንድነው
በቅርብ ጊዜ ውስጥ ትራፊክ ወደ ውስጣዊ አገልግሎቶች በተለየ መንገድ እንዘጋለን. OpenRestyን በመጠቀም የአሁኑን SSO በ OAuth ላይ ወደ ተኪ ለማዛወር አቅደናል። ቀድሞውኑ ብዙ ዝግጁ መፍትሄዎች እዚህ አሉ, ለምሳሌ:
ተጨማሪ ቁሳቁሶች
- JWT ቶከኖችን ለማረጋገጥ ጥሩ አገልግሎት
- የተረጋገጡ የ OIDC ትግበራዎች ዝርዝር
ምንጭ: hab.com