కొన్ని నెలల క్రితం నేను మా వందల కొద్దీ అంతర్గత అప్లికేషన్ల కోసం యాక్సెస్‌ని నిర్వహించడానికి OpenID Connect సర్వర్‌ని అమలు చేస్తున్నాను. మా స్వంత అభివృద్ధి నుండి, చిన్న స్థాయిలో సౌకర్యవంతంగా, మేము సాధారణంగా ఆమోదించబడిన ప్రమాణానికి మారాము. కేంద్ర సేవ ద్వారా ప్రాప్యత గణనీయంగా మార్పులేని కార్యకలాపాలను సులభతరం చేస్తుంది, అధికారాలను అమలు చేయడానికి అయ్యే ఖర్చును తగ్గిస్తుంది, అనేక రెడీమేడ్ పరిష్కారాలను కనుగొనడానికి మిమ్మల్ని అనుమతిస్తుంది మరియు కొత్త వాటిని అభివృద్ధి చేసేటప్పుడు మీ మెదడులను రాక్ చేయదు. ఈ వ్యాసంలో నేను ఈ పరివర్తన గురించి మరియు మేము కొట్టగలిగిన గడ్డల గురించి మాట్లాడుతాను.
చాలా కాలం క్రితం... ఎక్కడ మొదలైంది
చాలా సంవత్సరాల క్రితం, అంతర్గత అనువర్తనాలు మాన్యువల్‌గా నిర్వహించడానికి చాలా ఎక్కువ అయినప్పుడు, మేము కంపెనీలో యాక్సెస్‌ని నియంత్రించడానికి ఒక అప్లికేషన్‌ను వ్రాసాము. ఇది ఉద్యోగుల గురించిన సమాచారంతో డేటాబేస్కు కనెక్ట్ చేయబడిన ఒక సాధారణ రైల్స్ అప్లికేషన్, ఇక్కడ వివిధ కార్యాచరణలకు యాక్సెస్ కాన్ఫిగర్ చేయబడింది. అదే సమయంలో, మేము మొదటి SSOని ప్రారంభించాము, ఇది క్లయింట్ మరియు ఆథరైజేషన్ సర్వర్ నుండి టోకెన్ల ధృవీకరణ ఆధారంగా రూపొందించబడింది; టోకెన్ అనేక పారామితులతో ఎన్‌క్రిప్టెడ్ రూపంలో ప్రసారం చేయబడింది మరియు అధికార సర్వర్‌లో ధృవీకరించబడింది. ఇది అత్యంత అనుకూలమైన ఎంపిక కాదు, ఎందుకంటే ప్రతి అంతర్గత అప్లికేషన్ లాజిక్ యొక్క గణనీయమైన పొరను వివరించవలసి ఉంటుంది మరియు ఉద్యోగి డేటాబేస్‌లు పూర్తిగా అధికార సర్వర్‌తో సమకాలీకరించబడ్డాయి.
కొంత సమయం తరువాత, మేము కేంద్రీకృత అధికారం యొక్క పనిని సరళీకృతం చేయాలని నిర్ణయించుకున్నాము. SSO బ్యాలెన్సర్‌కు బదిలీ చేయబడింది. OpenResty సహాయంతో, టోకెన్‌లను తనిఖీ చేసే ఒక టెంప్లేట్ Luaకి జోడించబడింది, అభ్యర్థన ఏ అప్లికేషన్‌కు వెళుతుందో తెలుసుకుంటుంది మరియు అక్కడ యాక్సెస్ ఉందో లేదో తనిఖీ చేయవచ్చు. ఈ విధానం అంతర్గత అనువర్తనాలకు ప్రాప్యతను నియంత్రించే పనిని చాలా సులభతరం చేసింది - ప్రతి అప్లికేషన్ యొక్క కోడ్‌లో అదనపు లాజిక్‌ను వివరించాల్సిన అవసరం లేదు. ఫలితంగా, మేము ట్రాఫిక్‌ను బాహ్యంగా మూసివేసాము, కానీ అప్లికేషన్‌కు అధికారం గురించి ఏమీ తెలియదు.
అయితే, ఒక సమస్య పరిష్కారం కాలేదు. ఉద్యోగి సమాచారం అవసరమైన అప్లికేషన్ల గురించి ఏమిటి? ప్రామాణీకరణ సేవ కోసం APIని వ్రాయడం సాధ్యమైంది, అయితే మీరు అలాంటి ప్రతి అప్లికేషన్‌కు అదనపు లాజిక్‌ను జోడించాలి. అదనంగా, మా అంతర్గత అధికార సర్వర్‌లో ఓపెన్‌సోర్స్‌లోకి అనువాదంపై మరింత దృష్టి కేంద్రీకరించిన మా స్వీయ-వ్రాతపూర్వక అప్లికేషన్‌లలో ఒకదానిపై ఆధారపడటాన్ని మేము వదిలించుకోవాలనుకుంటున్నాము. మేము దాని గురించి మరొకసారి మీకు చెప్తాము. రెండు సమస్యలకు పరిష్కారం OAuth.
సాధారణంగా ఆమోదించబడిన ప్రమాణాల వైపు
OAuth అనేది స్పష్టమైన, సాధారణంగా ఆమోదించబడిన అధికార ప్రమాణం, కానీ దాని కార్యాచరణ మాత్రమే సరిపోదు కాబట్టి, OpenID Connect (OIDC) వెంటనే పరిగణించబడుతుంది. OIDC అనేది బహిరంగ ప్రమాణీకరణ ప్రమాణం యొక్క మూడవ అమలు, ఇది OAuth 2.0 ప్రోటోకాల్ (ఓపెన్ ఆథరైజేషన్ ప్రోటోకాల్) యొక్క సూపర్‌సెట్‌గా పరిణామం చెందింది. ఈ పరిష్కారం తుది వినియోగదారు గురించి డేటా లేకపోవడం సమస్యను పరిష్కరిస్తుంది మరియు ప్రామాణీకరణ ప్రొవైడర్‌ను మార్చడాన్ని కూడా సాధ్యం చేస్తుంది.
అయినప్పటికీ, మేము నిర్దిష్ట ప్రొవైడర్‌ను ఎంచుకోలేదు మరియు మా ప్రస్తుత అధికార సర్వర్‌కు OIDCతో ఏకీకరణను జోడించాలని నిర్ణయించుకున్నాము. తుది వినియోగదారు అధికార పరంగా OIDC చాలా అనువైనది అనే వాస్తవం ఈ నిర్ణయానికి మద్దతు ఇచ్చింది. అందువల్ల, మీ ప్రస్తుత అధికార సర్వర్‌లో OIDC మద్దతును అమలు చేయడం సాధ్యమైంది.
మా స్వంత OIDC సర్వర్‌ని అమలు చేయడానికి మా మార్గం
1) డేటాను అవసరమైన ఫారమ్‌లోకి తీసుకురండి
OIDCని ఏకీకృతం చేయడానికి, ప్రస్తుత వినియోగదారు డేటాను ప్రామాణికంగా అర్థం చేసుకోగలిగే రూపంలోకి తీసుకురావడం అవసరం. OIDCలో దీనిని క్లెయిమ్స్ అంటారు. బ్రాండ్‌లు తప్పనిసరిగా వినియోగదారు డేటాబేస్‌లోని చివరి ఫీల్డ్‌లు (పేరు, ఇమెయిల్, ఫోన్ మొదలైనవి). ఉనికిలో ఉంది , మరియు ఈ జాబితాలో చేర్చని ప్రతిదీ కస్టమ్‌గా పరిగణించబడుతుంది. అందువల్ల, మీరు ఇప్పటికే ఉన్న OIDC ప్రొవైడర్‌ను ఎంచుకోవాలనుకుంటే మీరు శ్రద్ధ వహించాల్సిన మొదటి అంశం ఏమిటంటే, కొత్త స్టాంపులను సౌకర్యవంతంగా అనుకూలీకరించగల సామర్థ్యం.
మార్కుల సమూహం క్రింది ఉపసమితిలో మిళితం చేయబడింది - స్కోప్. అధికార సమయంలో, స్కోప్ నుండి కొన్ని మార్కులు అవసరం లేకపోయినా నిర్దిష్ట మార్కులకు కాకుండా స్కోప్‌లకు యాక్సెస్ అభ్యర్థించబడుతుంది.
2) అవసరమైన గ్రాంట్లు అమలు
OIDC ఇంటిగ్రేషన్ యొక్క తదుపరి భాగం గ్రాంట్లు అని పిలువబడే అధికార రకాల ఎంపిక మరియు అమలు. ఎంచుకున్న అప్లికేషన్ మరియు అధికార సర్వర్ మధ్య పరస్పర చర్య యొక్క తదుపరి దృశ్యం ఎంచుకున్న గ్రాంట్‌పై ఆధారపడి ఉంటుంది. సరైన గ్రాంట్‌ను ఎంచుకోవడానికి సుమారు పథకం క్రింది చిత్రంలో ప్రదర్శించబడింది.
మా మొదటి అప్లికేషన్ కోసం, మేము అత్యంత సాధారణ గ్రాంట్‌ని ఉపయోగించాము - ఆథరైజేషన్ కోడ్. ఇతరుల నుండి దాని తేడా ఏమిటంటే ఇది మూడు-దశలు, అనగా. అదనపు పరీక్షకు లోనవుతుంది. మొదట, వినియోగదారు అధికార అనుమతి కోసం అభ్యర్థన చేస్తారు, ఆథరైజేషన్ కోడ్ టోకెన్‌ను అందుకుంటారు, ఆపై ఈ టోకెన్‌తో, ప్రయాణ టిక్కెట్‌తో ఉన్నట్లుగా, యాక్సెస్ టోకెన్‌ను అభ్యర్థిస్తుంది. ఈ ప్రామాణీకరణ దృశ్యం యొక్క అన్ని ప్రధాన పరస్పర చర్య అప్లికేషన్ మరియు అధికార సర్వర్ మధ్య దారిమార్పులపై ఆధారపడి ఉంటుంది. మీరు ఈ మంజూరు గురించి మరింత చదువుకోవచ్చు .
ప్రామాణీకరణ తర్వాత స్వీకరించబడిన యాక్సెస్ టోకెన్‌లు తాత్కాలికంగా ఉండాలి మరియు ప్రతి 10 నిమిషాలకు సగటున మార్చడం ఉత్తమం అనే భావనకు OAuth కట్టుబడి ఉంటుంది. ఆథరైజేషన్ కోడ్ మంజూరు అనేది దారిమార్పుల ద్వారా మూడు-దశల ధృవీకరణ; ప్రతి 10 నిమిషాలకు అటువంటి దశను చేయడం, స్పష్టంగా చెప్పాలంటే, కంటికి అత్యంత ఆహ్లాదకరమైన పని కాదు. ఈ సమస్యను పరిష్కరించడానికి, మరొక మంజూరు ఉంది - రిఫ్రెష్ టోకెన్, మేము కూడా ఉపయోగించాము. ఇక్కడ ప్రతిదీ సరళమైనది. మరొక మంజూరు నుండి ధృవీకరణ సమయంలో, ప్రధాన యాక్సెస్ టోకెన్‌తో పాటు, మరొకటి జారీ చేయబడుతుంది - రిఫ్రెష్ టోకెన్, ఇది ఒకసారి మాత్రమే ఉపయోగించబడుతుంది మరియు దాని జీవితకాలం, ఒక నియమం వలె, గణనీయంగా ఎక్కువ. ఈ రిఫ్రెష్ టోకెన్‌తో, ప్రధాన యాక్సెస్ టోకెన్ యొక్క TTL (లైవ్ టు లైవ్ సమయం) ముగిసినప్పుడు, కొత్త యాక్సెస్ టోకెన్ కోసం అభ్యర్థన మరొక మంజూరు యొక్క ముగింపు స్థానానికి వస్తుంది. ఉపయోగించిన రిఫ్రెష్ టోకెన్ వెంటనే సున్నాకి రీసెట్ చేయబడుతుంది. ఈ తనిఖీ రెండు-దశలు మరియు వినియోగదారు గుర్తించకుండా నేపథ్యంలో నిర్వహించబడుతుంది.
3) కాన్ఫిగర్ చేయబడిన వినియోగదారు డేటా అవుట్‌పుట్ ఫార్మాట్‌లు
ఎంచుకున్న గ్రాంట్లు అమలు చేయబడిన తర్వాత, అధికారం పనిచేస్తుంది, ఇది తుది వినియోగదారు డేటా యొక్క రసీదుని పేర్కొనడం విలువ. OIDCకి దీని కోసం ప్రత్యేక ముగింపు స్థానం ఉంది, ఇక్కడ మీరు మీ ప్రస్తుత యాక్సెస్ టోకెన్‌తో వినియోగదారు డేటాను అభ్యర్థించవచ్చు మరియు అది తాజాగా ఉంటే. మరియు వినియోగదారు డేటా చాలా తరచుగా మారకపోతే, కానీ మీరు ప్రస్తుత వాటి కోసం చాలాసార్లు వెళ్లాలి, మీరు JWT టోకెన్ల వంటి పరిష్కారానికి రావచ్చు. ఈ టోకెన్‌లకు ప్రమాణం కూడా మద్దతు ఇస్తుంది. JWT టోకెన్ మూడు భాగాలను కలిగి ఉంటుంది: హెడర్ (టోకెన్ గురించి సమాచారం), పేలోడ్ (ఏదైనా అవసరమైన డేటా) మరియు సంతకం (సంతకం, టోకెన్ సర్వర్ ద్వారా సంతకం చేయబడింది మరియు భవిష్యత్తులో మీరు దాని సంతకం యొక్క మూలాన్ని తనిఖీ చేయవచ్చు).
OIDC అమలులో, JWT టోకెన్‌ను id_token అంటారు. ఇది సాధారణ యాక్సెస్ టోకెన్‌తో పాటు అభ్యర్థించవచ్చు మరియు సంతకాన్ని ధృవీకరించడం మాత్రమే మిగిలి ఉంది. ఈ ప్రయోజనం కోసం, ఆథరైజేషన్ సర్వర్ ఫార్మాట్‌లో పబ్లిక్ కీల సమూహంతో ప్రత్యేక ముగింపు బిందువును కలిగి ఉంది . మరియు దీని గురించి మాట్లాడుతూ, ప్రమాణం ఆధారంగా మరొక ముగింపు స్థానం ఉందని పేర్కొనడం విలువ 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ని కలిగి ఉంది, ఇది అవసరమైన అన్ని బదిలీ చర్యలను పూర్తి చేయడానికి మిమ్మల్ని అనుమతిస్తుంది.
ధృవీకరించబడిన, ఆసక్తికరమైన, నా అభిప్రాయం ప్రకారం, అమలుకు మరొక ఉదాహరణ ఓరీ హైడ్రా. ఇది వివిధ భాగాలను కలిగి ఉన్నందున ఇది ఆసక్తికరంగా ఉంటుంది. ఇంటిగ్రేట్ చేయడానికి, మీరు మీ వినియోగదారు నిర్వహణ సేవను వారి అధికార సేవకు లింక్ చేయాలి మరియు అవసరమైన విధంగా విస్తరించాలి.
Keycloak మరియు Ory Hydra మాత్రమే రెడీమేడ్ పరిష్కారాలు కాదు. OpenID ఫౌండేషన్ ద్వారా ధృవీకరించబడిన అమలును ఎంచుకోవడం ఉత్తమం. ఈ పరిష్కారాలు సాధారణంగా OpenID సర్టిఫికేషన్ బ్యాడ్జ్‌ని కలిగి ఉంటాయి.
మీరు మీ OIDC సర్వర్‌ని ఉంచకూడదనుకుంటే, ఇప్పటికే ఉన్న చెల్లింపు ప్రొవైడర్ల గురించి మర్చిపోవద్దు. నేడు చాలా మంచి ఎంపికలు ఉన్నాయి.
తదుపరి ఏమిటి
సమీప భవిష్యత్తులో, మేము వేరే మార్గంలో అంతర్గత సేవలకు ట్రాఫిక్‌ను మూసివేయబోతున్నాము. మేము OAuth ఆధారంగా ప్రాక్సీకి OpenRestyని ఉపయోగించి బాలన్సర్‌లో మా ప్రస్తుత SSOని తరలించాలని ప్లాన్ చేస్తున్నాము. ఇక్కడ అనేక రెడీమేడ్ పరిష్కారాలు కూడా ఉన్నాయి, ఉదాహరణకు:
అదనపు పదార్థాలు
- JWT టోకెన్‌లను తనిఖీ చేయడానికి మంచి సేవ
- ధృవీకరించబడిన OIDC అమలుల జాబితా
మూలం: www.habr.com