OpenID සහ OAuth අතර වෙනස කුමක්ද?

මම ඇත්තටම උත්සාහ කරන්නේ OpenID සහ OAuth අතර වෙනස තේරුම් ගැනීමටද? සමහර විට ඒවා මුළුමනින්ම වෙනම දේවල් දෙකක් විය හැකිද?

OpenID යනු සත්‍යාපනය පිළිබඳවය (එනම් ඔබ කවුරුන්ද යන්න ඔප්පු කිරීම), OAuth යනු බලය පැවරීමයි (එනම් ක්‍රියාකාරීත්වය / දත්ත / යනාදිය සඳහා ප්‍රවේශය ලබා දීම. මුල් සත්‍යාපනය සමඟ ගනුදෙනු නොකර).

OAuth භාවිතා කරන්නෙකු නැවත සත්‍යාපනය නොකර ආරක්ෂිත දත්ත වෙත ප්‍රවේශ වීමට බාහිර හවුල්කාර අඩවි වල භාවිතා කළ හැකිය.

" OpenID එදිරිව OAuth හා පරිශීලකයාගේ දෘෂ්ටි කෝණයෙන් " යන බ්ලොග් සටහන පරිශීලකයාගේ දෘෂ්ටිකෝණයෙන් සරල සංසන්දනයක් ඇති අතර " OAuth-OpenID: ඔබ එකම ගස යැයි සිතන්නේ නම් ඔබ වැරදි ගස උසුලයි " වැඩි විස්තර ඇත ඒ ගැන.

OAuth සහ OpenID සංසන්දනය කිරීමට ක්‍රම තුනක් තිබේ:

1. අරමුණු

OpenID නිර්මාණය කර ඇත්තේ ෆෙඩරල් සත්‍යාපනය සඳහා ය, එනම්, ඔබේ පරිශීලකයින්ට දැනටමත් ඇති ගිණුම් භාවිතා කරමින් තෙවන පාර්ශවයකට ඔබ වෙනුවෙන් සත්‍යාපනය කිරීමට ඉඩ දෙන්න . ෆෙඩරේටඩ් යන පදය මෙහි ඉතා වැදගත් වන්නේ OpenID හි සමස්ත කරුණ වන්නේ ඕනෑම සැපයුම්කරුවෙකු භාවිතා කළ හැකි බැවිනි (සුදු ලැයිස්තු හැර). පරිශීලකයින්ට තමන් සතුව ඇති වෙනත් ගිණුමක් භාවිතා කිරීමට ඉඩ දීම සඳහා සැපයුම්කරුවන් සමඟ ගනුදෙනුවක් කලින් තෝරා ගැනීමට හෝ සාකච්ඡා කිරීමට ඔබට අවශ්‍ය නැත.

OAuth නිර්මාණය කරන ලද්දේ පරිශීලකයින්ට ඔවුන්ගේ මුරපද තෙවන පාර්ශවීය යෙදුම් සමඟ බෙදා ගැනීමේ අවශ්‍යතාවය ඉවත් කිරීම සඳහා ය . එය සැබවින්ම ආරම්භ වූයේ OpenID ගැටළුවක් විසඳීමේ ක්‍රමයක් ලෙස ය: ඔබ ඔබේ වෙබ් අඩවියේ OpenID සඳහා සහය දක්වන්නේ නම්, ඔබේ වෙබ් අඩවියේ පරිශීලකයින්ට මුරපදයක් නොමැති නිසා API එකක් ලබා දීමට ඔබට HTTP මූලික අක්තපත්‍ර (පරිශීලක නාමය සහ මුරපදය) භාවිතා කළ නොහැක.

ගැටළුව වන්නේ සත්‍යාපනය සඳහා OpenID වෙන් කිරීම සහ බලය පැවරීම සඳහා OAuth යනු ප්‍රොටෝකෝල දෙකටම එකම දේ බොහෝමයක් ඉටු කළ හැකි වීමයි. ඒවා සෑම එකක්ම විවිධ ක්‍රියාත්මක කිරීම් මගින් අපේක්‍ෂා කරන වෙනස් අංග සමූහයක් සපයන නමුත් අත්‍යවශ්‍යයෙන්ම ඒවා එකිනෙකට හුවමාරු වේ. ඔවුන්ගේ හරය තුළ, ප්‍රොටෝකෝල දෙකම ප්‍රකාශ කිරීමේ සත්‍යාපන ක්‍රමයක් වේ (OpenID යනු 'මම කවුද' යන ප්‍රකාශයට සීමා වී ඇති අතර, OAuth විසින් API හරහා ඕනෑම සහය දක්වන ප්‍රකාශයක් සඳහා හුවමාරු කර ගත හැකි 'ප්‍රවේශ ටෝකනයක්' සපයයි).

2. විශේෂාංග

මෙම ප්‍රොටෝකෝල දෙකම වෙබ් අඩවියකට පරිශීලකයෙකු වෙනත් තැනකට හරවා යැවිය හැකි අතර සත්‍යාපිත ප්‍රකාශයක් සමඟ නැවත පැමිණේ. OpenID විසින් අනන්‍යතා ප්‍රකාශයක් සපයන අතර OAuth ප්‍රවේශ ටෝකනයක ස්වරූපයෙන් වඩාත් සාමාන්‍ය වන අතර එය "OAuth සැපයුම්කරුගෙන් ප්‍රශ්න ඇසීමට" භාවිතා කළ හැකිය . කෙසේ වෙතත්, ඔවුන් එක් එක් වෙනස් අංග සඳහා සහාය දක්වයි:

OpenID - OpenID හි වැදගත්ම ලක්ෂණය වන්නේ එහි සොයාගැනීමේ ක්‍රියාවලියයි. OpenID ඔබට කලින් භාවිතා කිරීමට අවශ්‍ය සෑම සැපයුම්කරුවෙකුටම දෘඩ කේත කිරීමක් අවශ්‍ය නොවේ. සොයාගැනීම භාවිතා කරමින්, පරිශීලකයාට සත්‍යාපනය කිරීමට අවශ්‍ය ඕනෑම තෙවන පාර්ශවීය සැපයුම්කරුවෙකු තෝරා ගත හැකිය. මෙම සොයාගැනීමේ ලක්ෂණය OpenID හි බොහෝ ගැටළු වලටද හේතු වී ඇත, මන්ද එය ක්‍රියාත්මක කරන ආකාරය බොහෝ වෙබ් පරිශීලකයින්ට නොලැබෙන හඳුනාගැනීම් ලෙස HTTP URI භාවිතා කිරීමයි. OpenID සතුව ඇති අනෙකුත් ලක්ෂණ වන්නේ ඩීඑච් හුවමාරුවක් භාවිතා කරමින් තාවකාලික සේවාදායකයින් ලියාපදිංචි කිරීම, ප්‍රශස්ත අවසන් පරිශීලක අත්දැකීම් සඳහා ක්ෂණික මාදිලිය සහ සැපයුම්කරු වෙත තවත් වට-සංචාරයක් නොකර ප්‍රකාශයන් සත්‍යාපනය කිරීමේ මාර්ගයකි.

OAuth - OAuth හි වැදගත්ම ලක්ෂණය වන්නේ අමතර ඉල්ලීම් කිරීමේ දීර් last කාලීන ක්‍රමයක් සපයන ප්‍රවේශ ටෝකනයයි. OpenID මෙන් නොව, OAuth සත්‍යාපනයෙන් අවසන් නොවන අතර එකම තෙවන පාර්ශවීය සේවාවක් මගින් සපයනු ලබන අතිරේක සම්පත් වෙත ප්‍රවේශය ලබා ගැනීම සඳහා ප්‍රවේශ ටෝකනයක් සපයයි. කෙසේ වෙතත්, OAuth සොයා ගැනීම සඳහා සහය නොදක්වන බැවින්, ඔබ භාවිතා කිරීමට තීරණය කරන සැපයුම්කරුවන් කලින් තෝරා ගැනීම සහ දෘඩ කේත කිරීම අවශ්‍ය වේ. ඔබේ වෙබ් අඩවියට පිවිසෙන පරිශීලකයෙකුට කිසිදු හඳුනාගැනීමක් භාවිතා කළ නොහැක, ඔබ විසින් කලින් තෝරාගත් අය පමණි. එසේම, OAuth හට අනන්‍යතා සංකල්පයක් නොමැති බැවින් එය පුරනය වීම සඳහා භාවිතා කිරීම යන්නෙන් අදහස් කරන්නේ අභිරුචි පරාමිතියක් එකතු කිරීම (ට්විටර් විසින් සිදු කරන ලද පරිදි) හෝ දැනට "පුරනය වී ඇති" පරිශීලකයා ලබා ගැනීම සඳහා වෙනත් API ඇමතුමක් ලබා ගැනීමයි.

3. තාක්ෂණික ක්‍රියාත්මක කිරීම

පරිශීලක අවසරය ලබා ගැනීම සඳහා යළි හරවා යැවීම භාවිතා කිරීමේදී මෙම ප්‍රොටෝකෝල දෙක පොදු ගෘහ නිර්මාණ ශිල්පයක් බෙදා ගනී. OAuth හි පරිශීලකයා ඔවුන්ගේ ආරක්ෂිත සම්පත් සහ OpenID හි ඔවුන්ගේ අනන්‍යතාවයට ප්‍රවේශ වීමට අවසර දෙයි. නමුත් ඔවුන් බෙදා ගන්නේ එපමණයි.

සෑම ප්‍රොටෝකෝලයක්ම ඉල්ලීමේ හෝ ප්‍රතිචාරයේ සත්‍යතාව තහවුරු කිරීම සඳහා භාවිතා කරන අත්සනක් ගණනය කිරීමේ වෙනස් ක්‍රමයක් ඇති අතර, එක් එක් වෙනස් ලියාපදිංචි අවශ්‍යතා ඇත.

OpenID යනු (ප්‍රධාන වශයෙන්) හඳුනා ගැනීම / සත්‍යාපනය සඳහා වන අතර එමඟින් stackoverflow.comමා සතු chris.boyle.name(හෝ කොතැනක හෝ) හිමිකමක් ඇති බවත් ඒ නිසා මම chris.boyle.nameඊයේ අයිති කර ගෙන කීර්ති නාම ලබා ගත් එකම පුද්ගලයා විය හැකි බවත් දනී .

OAuth නිර්මාණය කර ඇත්තේ ඔබ වෙනුවෙන් ක්‍රියාමාර්ග ගැනීමට බලය පැවරීම සඳහා වන අතර එමඟින් stackoverflow.com(හෝ ඕනෑම තැනක) ඔබේ ට්විටර් මුරපදය නොදැන ස්වයංක්‍රීයව ඔබ වෙනුවෙන් ට්වීට් කිරීමට අවසර ඉල්ලිය හැකිය.

බොහෝ අය තවමත් මෙය නැරඹීමට පැමිණ ඇති බැවින් එය පැහැදිලි කිරීම සඳහා ඉතා සරල රූප සටහනක් මෙහි ඇත

අනුග්‍රහය විකිපීඩියා

OAuth

පැවරීම සඳහා authorizationපමණක් භාවිතා කරයි - එයින් අදහස් වන්නේ මුරපදයක් ලබා නොදී පුද්ගලික දත්ත භාවිතා කිරීමට ඔබ තෙවන පාර්ශවීය සේවා ප්‍රවේශයකට අවසර දී ඇති බවයි. OAuth "සැසි" සාමාන්‍යයෙන් පරිශීලක සැසි වලට වඩා දිගු කාලයක් ජීවත් වේ. OAuth නිර්මාණය කර ඇත්තේ බලය පැවරීමට ඉඩ දීම සඳහා ය

එනම්, ෆ්ලිකර් OAuth භාවිතා කරන්නේ තෙවන පාර්ශවීය සේවාවන්ට ඔවුන්ගේ ෆ්ලිකර් පරිශීලක නාමය සහ මුරපදය ලබා නොදී, ඔවුන් වෙනුවෙන් පුද්ගල පින්තූරයක් පළ කිරීමට සහ සංස්කරණය කිරීමට ඉඩ දීම සඳහා ය.

OpenID

කිරීම සඳහා භාවිතා authenticateතනි පුරනය මත අනන්යතාව. සියලු OpenID විසින් කළ යුතුව ඇත්තේ ඔබ යැයි ඔබ ඔප්පු කිරීමට OpenID සැපයුම්කරුවෙකුට ඉඩ දීමයි. කෙසේ වෙතත් බොහෝ වෙබ් අඩවි බලය පැවරීම සඳහා අනන්‍යතා සත්‍යාපනය භාවිතා කරයි (කෙසේ වෙතත් දෙක වෙන් කළ හැකිය)

එනම්, ඔවුන් භාවිතා කරන ටිකට් පතේ සිටින පුද්ගලයාගේ නම සත්‍යාපනය කිරීමට (හෝ ඔප්පු කිරීමට) ඔවුන්ගේ ගුවන් ගමන් බලපත්‍රය ගුවන් තොටුපලේදී පෙන්වයි.

ඔබේ පරිශීලකයින්ට ෆේස්බුක් හෝ ට්විටර් සමඟ ප්‍රවේශ වීමට අවශ්‍ය නම් OAuth භාවිතා කරන්න. ඔබේ පරිශීලකයින් තමන්ගේම OpenID සපයන්නන් පවත්වාගෙන යන බෙල්ලන් නම් OpenID භාවිතා කරන්න, මන්ද ඔවුන්ට "වෙනත් කිසිවෙකුට ඔවුන්ගේ අනන්‍යතාවය අයිති කර ගැනීමට අවශ්‍ය නැති නිසා".

• OpenID යනු OpenID පදනම විසින් පාලනය කරනු ලබන විවෘත සම්මත හා විමධ්‍යගත සත්‍යාපන ප්‍රොටෝකෝලයකි.
• OAuth යනු ප්‍රවේශ නියෝජිතයින් සඳහා විවෘත ප්‍රමිතියකි .
• OpenID Connect (OIDC) OpenID සහ OAuth හි අංගයන් ඒකාබද්ධ කරයි, එනම් සත්‍යාපනය සහ බලය පැවරීම යන දෙකම කරයි.

OpenID සමහර "OpenID සැපයුම්කරු" විසින් පාලනය කරන අද්විතීය URI ස්වරූපයක් ගනී, එනම් අනන්‍යතා සැපයුම්කරු (idP).

OAuth XACML සමඟ ඒකාබද්ධව භාවිතා කළ හැකි අතර OAuth හිමිකාරිත්වය සහ ප්‍රවේශ නියෝජිත කණ්ඩායම සඳහා OAuth භාවිතා කරන අතර XACML බලය පැවරීමේ ප්‍රතිපත්ති නිර්වචනය කිරීමට භාවිතා කරයි.

OIDC සරල JSON වෙබ් ටෝකන (JWT) භාවිතා කරයි, එය ඔබට OAuth 2.0 පිරිවිතරයන්ට අනුකූල වන ප්‍රවාහ භාවිතා කර ලබා ගත හැකිය . OAuth යනු OIDC සමඟ කෙලින්ම සම්බන්ධ වන බැවින් OIDC යනු OAuth 2.0 මත ගොඩනගා ඇති සත්‍යාපන ස්ථරයකි .

උදාහරණයක් ලෙස , ඔබ ඔබගේ ගූගල් ගිණුම භාවිතයෙන් Auth0 වෙත පුරනය වීමට තෝරා ගත්තේ නම් ඔබ භාවිතා කළේ OIDC ය . ඔබ ගූගල් සමඟ සාර්ථකව සත්‍යාපනය කළ පසු සහ ඔබේ තොරතුරු වෙත ප්‍රවේශ වීමට Auth0 වෙත බලය පැවරූ පසු , ගූගල් විසින් පරිශීලකයා පිළිබඳ තොරතුරු Auth0 වෙත යවනු ලැබේ . මෙම තොරතුරු JSON වෙබ් ටෝකනයකින් (JWT) යවනු ලැබේ . ඔබට ප්‍රවේශ ටෝකනයක් ලැබෙනු ඇති අතර, ඉල්ලුවහොත් ID හැඳුනුම්පතක් ලැබෙනු ඇත. ටෝකන් වර්ග : මූලාශ්‍රය: OpenID Connect

ප්‍රතිසම :
සංවිධානයක් හැඳුනුම්පත් සඳහා හැඳුනුම්පතක් භාවිතා කරන අතර එහි චිප්ස් අඩංගු වන අතර, එහි සේවකයා පිළිබඳ විස්තර සහ බලය පැවරීම එනම් කැම්පස් / ගේට් / ඕඩීසී ප්‍රවේශය ගබඩා කරයි . හැඳුනුම්පත ලෙස කාඩ් ක්රියාව OIDC සහ චිප් ලෙස ක්රියා OAuth . තවත් උදාහරණ සහ විකිය සාදන්න

OpenID සහ OAuth යනු සත්‍යාපනය සහ / හෝ බලය පැවරීම සඳහා වන සෑම HTTP- පදනම් වූ ප්‍රොටෝකෝලයකි. සේවාදායකයින්ට හෝ තෙවන පාර්ශවයන්ට සත්‍යාපන අක්තපත්‍ර හෝ බ්ලැන්කට් අවසර ලබා නොදී ක්‍රියා කිරීමට පරිශීලකයින්ට ඉඩ දීම මේ දෙකේම අරමුණයි. ඒවා සමාන වන අතර ඒවා දෙකම එකට භාවිතා කිරීමට යෝජිත ප්‍රමිතීන් ඇතත් ඒවා වෙනම ප්‍රොටෝකෝල වේ.

OpenID ෆෙඩරල් සත්‍යාපනය සඳහා අදහස් කෙරේ. සේවාදායකයෙකු ඕනෑම සැපයුම්කරුවෙකුගෙන් අනන්‍යතා ප්‍රකාශයක් භාර ගනී (සේවාදායකයින්ට සුදු ලැයිස්තු ගත කිරීමට හෝ සැපයුම්කරුවන්ගේ ලැයිස්තු ගත කිරීමට නිදහස තිබුණද).

OAuth පවරා ඇත්තේ බලය පැවරීම සඳහා ය. සේවාදායකයා සැපයුම්කරුවෙකු සමඟ ලියාපදිංචි වන අතර එය බලය පැවරීමේ ටෝකන ලබා දෙන අතර එය පරිශීලකයා වෙනුවෙන් ක්‍රියා කිරීමට පිළිගනී.

OAuth දැනට අවසරය සඳහා වඩාත් සුදුසුය, මන්ද සත්‍යාපනයෙන් පසුව තවත් අන්තර්ක්‍රියා ප්‍රොටෝකෝලය තුළට ගොඩනගා ඇති නමුත් ප්‍රොටෝකෝල දෙකම පරිණාමය වෙමින් පවතී. OpenID සහ එහි දිගු කිරීම් බලය පැවරීම සඳහා භාවිතා කළ හැකි අතර OAuth සත්‍යාපනය සඳහා භාවිතා කළ හැකිය, එය විකල්ප අවසරයක් ලෙස සිතිය හැකිය.

OpenID, OAuth, OpenID Connect අතර වෙනස පැහැදිලි කිරීම:

OpenID යනු සත්‍යාපනය සඳහා වන ප්‍රොටෝකෝලයක් වන අතර OAuth අවසරය සඳහා වේ. සත්‍යාපනය යනු ඔබ කතා කරන පුද්ගලයා ඇත්ත වශයෙන්ම ඔහු යැයි කියාගන්නා පුද්ගලයා බව තහවුරු කර ගැනීමයි. බලය පැවරීම යනු එම පුද්ගලයාට කුමක් කළ යුතුද යන්න තීරණය කිරීමයි.

OpenID හි, සත්‍යාපනය පවරා ඇත: සේවාදායකය A පරිශීලකයා සත්‍යාපනය කිරීමට අවශ්‍ය නමුත් U හි අක්තපත්‍ර (උදා: U ගේ නම සහ මුරපදය) වෙනත් සේවාදායකයක් වන B වෙත යවනු ලැබේ, ඒ විශ්වාසනීය (අවම වශයෙන් පරිශීලකයින් සත්‍යාපනය සඳහා විශ්වාස කරයි). ඇත්ත වශයෙන්ම, සේවාදායක B විසින් U සැබවින්ම U බව සහතික කර පසුව A ට මෙසේ කියයි: "හරි, එය අව්‍යාජ U".

OAuth හි, බලය පැවරීම පවරා ඇත: වස්තුව A ආයතනයෙන් ලබා ගන්නේ “ප්‍රවේශවීමේ අයිතිය” වන අතර එය A සේවාදායකයට ප්‍රවේශය ලබා දිය හැකි බව පෙන්විය හැකිය; B ට වැඩි බලයක් ලබා නොදී A වෙත තාවකාලික, විශේෂිත ප්‍රවේශ යතුරු ලබා දිය හැකිය. විශාල හෝටලයක ප්‍රධාන ස්වාමියා ලෙස OAuth සේවාදායකයක් ඔබට සිතාගත හැකිය; ඔහු සේවකයින්ට ඇතුළු විය යුතු කාමරවල දොරවල් විවෘත කරන යතුරු ලබා දෙයි, නමුත් සෑම යතුරක්ම සීමිතය (එය සියලු කාමරවලට ප්‍රවේශය ලබා නොදේ); තව දුරටත්, යතුරු පැය කිහිපයකට පසු ස්වයං විනාශ කරයි.

යම් තාක් දුරට බලය පැවරීම කිසියම් ව්‍යාජ සත්‍යාපනයකට අනිසි ලෙස භාවිතා කළ හැකිය, ඒ අනුව A ආයතනය B වෙතින් ප්‍රවේශ යතුරක් OAuth හරහා ලබාගෙන එය S සේවාදායකයට පෙන්වයි නම්, සේවාදායකයා S ප්‍රවේශය ලබා දීමට පෙර B සත්‍යාපනය කළ බව අනුමාන කළ හැකිය. යතුර. එබැවින් සමහර අය OpenAID භාවිතා කළ යුතු තැන OAuth භාවිතා කරයි. මෙම ක්‍රමෝපාය බුද්ධිමත් විය හැකිය හෝ නොවිය හැකිය; නමුත් මම හිතන්නේ මෙම ව්‍යාජ සත්‍යාපනය සියල්ලටම වඩා ව්‍යාකූලයි. OpenID Connect එක කරන්නේ එයයි: එය OAuth සත්‍යාපන ප්‍රොටෝකෝලයක් ලෙස අනිසි ලෙස භාවිතා කරයි. හෝටල් ප්‍රතිසමයේදී: මට අපේක්ෂිත සේවකයෙකු මුණගැසුණහොත් සහ එම පුද්ගලයා මගේ කාමරය විවෘත කරන යතුරක් ඇති බව මට පෙන්වන්නේ නම්, මෙය සැබෑ සේවකයෙකු යැයි මම සිතමි, ප්‍රධාන ස්වාමියා ඔහුට යතුරක් ලබා නොදෙනු ඇත ඔහු නොසිටියා නම් එය මගේ කාමරය විවෘත කරයි.

(මූලාශ්රය)

OpenID 2.0 සම්බන්ධතාවය OpenID 2.0 ට වඩා වෙනස් වන්නේ කෙසේද?

OpenID Connect OpenID 2.0 හා සමාන බොහෝ කාර්යයන් ඉටු කරයි, නමුත් එසේ කරන්නේ API- හිතකාමී වන අතර දේශීය සහ ජංගම යෙදුම් සඳහා භාවිතා කළ හැකිය. OpenID Connect මගින් ශක්තිමත් අත්සන් කිරීම සහ සංකේතනය සඳහා විකල්ප යාන්ත්‍රණ අර්ථ දක්වයි. OAuth 1.0a සහ OpenID 2.0 ඒකාබද්ධ කිරීම සඳහා දිගුවක් අවශ්‍ය වන අතර, OpenID Connect හි OAuth 2.0 හැකියාවන් ප්‍රොටෝකෝලය සමඟ ඒකාබද්ධ වේ.

(මූලාශ්රය)

OpenID සම්බන්ධතාවය මඟින් ඔබට ප්‍රවේශ ටෝකනයක් සහ හැඳුනුම් ටෝකනයක් ලබා දෙනු ඇත. හැඳුනුම් ටෝකනය JWT වන අතර සත්‍යාපනය කළ පරිශීලකයා පිළිබඳ තොරතුරු අඩංගු වේ. එය අනන්‍යතා සැපයුම්කරු විසින් අත්සන් කර ඇති අතර අනන්‍යතා සැපයුම්කරු වෙත ප්‍රවේශ නොවී කියවා සත්‍යාපනය කළ හැකිය.

මීට අමතරව, ඕපන්අයිඩී සම්බන්ධතාවය මඟින් ඕට් 2 තේරීම දක්වා ඉතිරිවන කරුණු කිහිපයක් ප්‍රමිතිකරණය කරයි. උදාහරණයක් ලෙස විෂය පථයන්, අන්ත ලක්ෂ්‍ය සොයා ගැනීම සහ සේවාදායකයින් ගතිකව ලියාපදිංචි කිරීම.

බහු අනන්‍යතා සපයන්නන් අතර තෝරා ගැනීමට පරිශීලකයාට ඉඩ සලසන කේත ලිවීම මෙය පහසු කරයි.

(මූලාශ්රය)

ගූගල් හි OAuth 2.0

ගූගල් හි OAuth 2.0 API සත්‍යාපනය සහ බලය පැවරීම යන දෙකටම භාවිතා කළ හැකිය. මෙම ලේඛනය සත්‍යාපනය සඳහා අපගේ OAuth 2.0 ක්‍රියාත්මක කිරීම විස්තර කරයි, එය OpenID Connect පිරිවිතරයට අනුකූල වන අතර එය OpenID සහතික කර ඇත. ගූගල් ඒපීඅයි වෙත ප්‍රවේශ වීම සඳහා ඕඒත් 2.0 භාවිතා කිරීමෙහි ඇති ප්‍රලේඛනය මෙම සේවාවට ද අදාළ වේ. ඔබට මෙම ප්‍රොටෝකෝලය අන්තර්ක්‍රියාකාරීව ගවේෂණය කිරීමට අවශ්‍ය නම්, අපි නිර්දේශ කරන්නේ Google OAuth 2.0 ක්‍රීඩා පිටියයි .

(මූලාශ්රය)

අදහස් දැක්වීමේදී පෙන්වා දී ඇති පරිදි මෙම ප්‍රශ්නය නැවත සලකා බැලීම අර්ථවත් යැයි මම විශ්වාස කරමි, OpenID Connect හඳුන්වාදීම වඩාත් ව්‍යාකූලත්වයට හේතු වන්නට ඇත.

OpenID Connect යනු OpenID 1.0 / 2.0 වැනි සත්‍යාපන ප්‍රොටෝකෝලයකි, නමුත් එය සැබවින්ම OAuth 2.0 මත ගොඩනගා ඇත, එබැවින් ඔබට සත්‍යාපන විශේෂාංග සමඟ බලය පැවරීමේ අංග ලැබෙනු ඇත. මේ දෙක අතර වෙනස ඉතා හොඳින් විස්තර කර ඇත (සාපේක්ෂව මෑත, නමුත් වැදගත්) ලිපියේ: http://oauth.net/articles/authentication/

පිළිතුරකට වඩා ප්‍රශ්නයට දිගුවක්, නමුත් එය ඉහත විශිෂ්ට තාක්ෂණික පිළිතුරු සඳහා යම් ඉදිරිදර්ශනයක් එක් කළ හැකිය. මම ක්ෂේත්‍ර ගණනාවක පළපුරුදු ක්‍රමලේඛකයෙක්, නමුත් වෙබය සඳහා ක්‍රමලේඛනය කිරීම සඳහා මුලුමනින්ම. දැන් Zend Framework භාවිතා කර වෙබ් පාදක යෙදුමක් තැනීමට උත්සාහ කරයි.

නියත වශයෙන්ම යෙදුම්-විශේෂිත මූලික පරිශීලක නාමයක් / මුරපද සත්‍යාපන අතුරුමුහුණතක් ක්‍රියාත්මක කරනු ඇත, නමුත් වැඩිවෙමින් පවතින පරිශීලකයින් සංඛ්‍යාවක් සඳහා තවත් පරිශීලක නාමයක් සහ මුරපදයක් ගැන සිතීම වළක්වන බව හඳුනා ගන්න. හරියටම සමාජ ජාලයක් නොවූවත්, යෙදුමේ විභව භාවිතා කරන්නන්ගෙන් ඉතා විශාල ප්‍රතිශතයක් දැනටමත් ෆේස්බුක් හෝ ට්විටර් ගිණුම් ඇති බව මම දනිමි. යෙදුමට ඇත්ත වශයෙන්ම එම වෙබ් අඩවි වලින් පරිශීලකයාගේ ගිණුම පිළිබඳ තොරතුරු ලබා ගැනීමට අවශ්‍ය නැත, අවශ්‍ය නොවේ, පරිශීලකයාට අවශ්‍ය නොවන්නේ නම් නව ගිණුම් අක්තපත්‍ර සැකසීමට අවශ්‍ය නොවන පහසුව ලබා දීමට එය අවශ්‍ය වේ. ක්‍රියාකාරී දෘෂ්ටි කෝණයෙන් බලන කල, එය OpenID සඳහා පෝස්ටර් දරුවෙකු ලෙස පෙනේ. ෆේස්බුක් හෝ ට්විටර් යන දෙකම OpenID සපයන්නන් නොවන බව පෙනේ, ඔවුන් තම පරිශීලකයාගේ දත්ත වෙත ප්‍රවේශ වීම සඳහා OAuth සත්‍යාපනය සඳහා සහය දක්වයි.

මේ දෙක ගැන මා කියවා ඇති ලිපි හා ඒවා එකිනෙකට වෙනස් වන්නේ කෙසේද යන්න, ඉහත කාල් ඇන්ඩර්සන්ගේ නිරීක්‍ෂණය මා දකින තුරු, “OAuth සත්‍යාපනය සඳහා භාවිතා කළ හැකිය, එය විවෘත අවසරයක් ලෙස සිතිය හැකිය” OAuth මට කිරීමට අවශ්‍ය දේ සඳහා ප්‍රමාණවත් බව පැහැදිලි තහවුරු කිරීමක් මම දුටුවෙමි.

ඇත්ත වශයෙන්ම, මම මෙම "පිළිතුර" පළ කිරීමට ගිය විට, ඒ වන විට සාමාජිකයෙකු නොවීම, මා හඳුනා ගැනීමේ විකල්පයන් දෙස මම මෙම පිටුවේ පතුලේ දිගු හා දැඩි ලෙස බැලුවෙමි. OpenID පිවිසුමක් භාවිතා කිරීමට හෝ මා සතුව එකක් නොමැති නම් එකක් ලබා ගැනීමට ඇති විකල්පය, නමුත් ට්විටර් හෝ ෆේස්බුක් ගැන කිසිවක් යෝජනා නොකරන්නේ OAuth කාර්යය සඳහා ප්‍රමාණවත් නොවන බවයි. නමුත් පසුව මම තවත් කවුළුවක් විවෘත කර ස්ටක් ඕවර් ප්‍රවාහය සඳහා පොදු ලියාපදිංචි වීමේ ක්‍රියාවලියක් සොයා බැලුවෙමි. බලන්න, ෆේස්බුක් සහ ට්විටර් ඇතුළු තෙවන පාර්ශවීය සත්‍යාපන විකල්ප රාශියක් තිබේ. අවසානයේදී මම මගේ ගූගල් හැඳුනුම්පත (එය ඕපන්අයිඩී) භාවිතා කිරීමට තීරණය කළෙමි. මගේ මිතුරන්ගේ ලැයිස්තුවට ස්ටක් ඕවර් ප්‍රවාහ ප්‍රවේශය ලබා දීමට මට අවශ්‍ය නොවූ අතර වෙනත් ඕනෑම දෙයක් ෆේස්බුක් එහි පරිශීලකයින් ගැන බෙදා ගැනීමට කැමතියි - නමුත් අවම වශයෙන් එය '

මේ ආකාරයේ බහු-පාර්ශවීය බලය පැවරීමේ සැකසුමකට සහය දැක්වීම පිළිබඳ තොරතුරු ලබා ගැනීමට යමෙකුට තොරතුරු හෝ දර්ශකයන් පළ කළ හැකි නම් සහ බලය අවලංගු කරන හෝ ඔවුන්ගේ තෙවන පාර්ශවීය වෙබ් අඩවියට ප්‍රවේශය අහිමි වන පරිශීලකයින් සමඟ ඔබ කටයුතු කරන්නේ කෙසේද යන්න ඇත්තෙන්ම හොඳ ය. මෙහි ඇති මගේ පරිශීලක නාමය, මට එය සැකසීමට අවශ්‍ය නම් මූලික සත්‍යාපනය සමඟ ප්‍රවේශ විය හැකි අද්විතීය ස්ටැක් ඕවර් ප්‍රවාහ ගිණුමක් හදුනාගෙන ඇති බවත්, අනෙක් තෙවන පාර්ශවීය සත්‍යාපනය කරන්නන් හරහා මෙම ගිණුමට පිවිසිය හැකි බවත් මට හැඟේ (උදා: එබැවින් මම ලොග් වී ඇති බව සලකනු ලැබේ මම කිසියම් ගූගල්, ෆේස්බුක් හෝ ට්විටර් වෙත පිවිසී ඇත්නම් ස්ටක් ඕවර් ප්‍රවාහයට ...). මෙම වෙබ් අඩවිය එය කරන බැවින්, මෙහි සිටින කෙනෙකුට මෙම විෂය පිළිබඳ හොඳ අවබෝධයක් තිබිය හැකිය. :-)

කණගාටුයි, මෙය මෙතරම් දීර් was වූ අතර පිළිතුරකට වඩා ප්‍රශ්නයක් විය - නමුත් කාල්ගේ ප්‍රකාශය නිසා OAuth සහ OpenID හි නූල් පරිමාව මධ්‍යයේ පළ කිරීම වඩාත් සුදුසු ස්ථානයක් ලෙස පෙනුණි. මට හමු නොවූ මේ සඳහා වඩා හොඳ ස්ථානයක් තිබේ නම්, මම කල්තියාම සමාව ඉල්ලමි, මම උත්සාහ කළෙමි.

OpenID ඔබ කවුදැයි ඔප්පු කරයි.

OAuth විසින් බලයලත් පාර්ශවය විසින් සපයනු ලබන විශේෂාංග වෙත ප්‍රවේශය ලබා දේ.

මම දැනට OAuth 2.0 සහ OpenID connect spec හි වැඩ කරමින් සිටිමි. ඉතින් මගේ අවබෝධය මෙන්න: කලින් ඒවා වූයේ:

1. OpenID යනු ගූගල් හි හිමිකාරීත්වය ක්‍රියාත්මක කිරීම වන අතර ඔබට පුවත්පත් වෙබ් අඩවි වැනි තෙවන පාර්ශවීය යෙදුම් සඳහා ගූගල් භාවිතයෙන් ප්‍රවේශ විය හැකි අතර ලිපියක් පිළිබඳව අදහස් දැක්විය හැකිය. එබැවින් මූලික වශයෙන් පුවත්පත් වෙබ් අඩවියට මුරපද හුවමාරුවක් නොමැත. මෙහි අර්ථ දැක්වීමක් කිරීමට මට ඉඩ දෙන්න, ව්‍යවසාය ප්‍රවේශයේ මෙම ප්‍රවේශය සම්මේලනය ලෙස හැඳින්වේ. සම්මේලනයේදී, ඔබ සත්‍යාපනය සහ බලය පවරන සේවාදායකයක් ඇත (IDP, හැඳුනුම්පත් සපයන්නා ලෙස හැඳින්වේ) සහ සාමාන්‍යයෙන් පරිශීලක අක්තපත්‍ර භාරකරු. ඔබට ව්‍යාපාරයක් ඇති සේවාදායක යෙදුම SP හෝ සේවා සැපයුම්කරු ලෙස හැඳින්වේ. අපි නැවත එම පුවත්පත් වෙබ් අඩවි උදාහරණයට ගියහොත් පුවත්පත් වෙබ් අඩවිය මෙහි එස්පී වන අතර ගූගල් අවතැන් වේ. ව්‍යවසායයේදී මෙම ගැටළුව මීට පෙර SAML භාවිතයෙන් විසඳා ඇත. මෘදුකාංග කර්මාන්තය පාලනය කිරීම සඳහා XML භාවිතා කරන ලදී. එබැවින් වෙබ් සේවා සිට වින්‍යාසය දක්වා සෑම දෙයක්ම එක්ස්එම්එල් වෙත යාමට භාවිතා කරන බැවින් අපට SAML ඇත,

2. OAuth: OAuth එය මේ ආකාරයේ හිමිකාර ප්‍රවේශයන් දෙස බලන ප්‍රමිතියක් ලෙස ඉස්මතු වී ඇති අතර ඒ නිසා අපට OAuth 1.o ප්‍රමිතියක් ඇති නමුත් ආමන්ත්‍රණය කරන්නේ බලය පැවරීම පමණි. බොහෝ අය නොදැන සිටියද එය එක්තරා ආකාරයකින් තෝරා ගැනීමට පටන් ගත්තේය. 2012 දී අපට OAuth 2.0 තිබී ඇත. ලෝකය වලාකුළු පරිගණකකරණය දෙසට ගමන් කරමින් සිටින අතර පරිගණක උපාංග ජංගම හා වෙනත් උපාංග දෙසට ගමන් කරන බැවින් CTOs, ගෘහ නිර්මාණ ශිල්පීන් සැබවින්ම අවධානය යොමු කිරීමට පටන් ගත්හ. මෘදුකාංග ගනුදෙනුකරුවන් එක් සමාගමකට IDP සේවාව ලබා දිය හැකි අතර විකුණුම් බලකාය, SAP වැනි විවිධ වෙළෙන්දන්ගෙන් බොහෝ සේවාවන් ලබා ගත හැකි ප්‍රධාන ගැටළුව විසඳීම සඳහා OAuth කාර්‍යය සලකා බලයි. එබැවින් මෙහි ඒකාබද්ධ වීම සැබවින්ම සම්මේලනයේ තත්වය මෙන් පෙනේ, SAML භාවිතා කිරීම මිල අධිකය එබැවින් OAuth 2.o ගවේෂණය කරමු. ඔහ්, එක් වැදගත් කරුණක් මග හැරී ඇත, මේ කාලය තුළ ගූගල්ට දැනුනේ OAuth ඇත්ත වශයෙන්ම එසේ නොවන බවයි

   ඒ. OAuth 2.o පැහැදිලිව නොකියයි, සේවාදායකයින් ලියාපදිංචි වන්නේ කෙසේද b. එස්පී (සම්පත් සේවාදායකය) සහ සේවාදායක යෙදුම අතර අන්තර්ක්‍රියාකාරිත්වය ගැන එහි කිසිවක් සඳහන් නොවේ (දත්ත සපයන විශ්ලේෂණ සේවාදායකය සම්පත් සේවාදායකය සහ දත්ත සේවාදායකයා බව පෙන්වන යෙදුම වැනි)

තාක්‍ෂණිකව දැනටමත් අපූරු පිළිතුරු ලබා දී ඇත, කෙටි පරිණාමය ඉදිරිදර්ශනයක් ලබා දීමට මම සිතුවෙමි

මෙම අදහස් දැක්වීමේදී ග්‍රහණය කර ඇති පරිදි මෙම ප්‍රශ්නයේ විශේෂිත අංගයක් ඇමතීමට මම කැමතියි:

OAuth: කිසියම් අංගයකට ප්‍රවේශය ලබා දීමට පෙර, සත්‍යාපනය කළ යුතුය, නේද?. ඉතින් OAuth = සමහර විශේෂාංග සඳහා ප්‍රවේශය ලබා දෙන OpenId + කුමක්ද? - හසන් මාකරොව් ජුනි 21 at 1:57

ඔව් ... නැහැ. පිළිතුර සියුම් ය, එබැවින් මා සමඟ ඉවසන්න.

මෙම OAuth ගලා වේ (එය මෙම OAuth සැපයුම්කරු) ඉලක්කයක් සේවයට ඔබ යළි-යොමුකරයි විට, එය වේ සංකේත සේවාදායකයාගේ අයදුම් / සේවා බාර දී ඇති නිසා නැවත පෙර ඔබ එම සේවය සමඟ සත්යතාවයක් කිරීමට අවශ්ය බව ඉඩ. එහි ප්‍රති ing ලයක් ලෙස ටෝකනය ලබා දී ඇති පරිශීලකයෙකු වෙනුවෙන් ඉල්ලීම් කිරීමට ග්‍රාහක යෙදුමට ඉඩ දෙයි.

එම අවසාන වාක්‍යයේ සාමාන්‍යභාවය සැලකිල්ලට ගන්න: විශේෂයෙන්, මම ලියා ඇත්තේ “දී ඇති පරිශීලකයෙකු වෙනුවෙන්” මිස “ ඔබ වෙනුවෙන් ” නොවේ. “දී ඇති පරිශීලකයෙකු සතු සම්පතක් සමඟ අන්තර් ක්‍රියා කිරීමේ හැකියාවක් තිබීම” යන්නෙන් අදහස් කරන්නේ “ඔබ සහ ඉලක්කගත සම්පත් (ය) හි හිමිකරු එක හා සමානයි” යන්නයි.

මෙම වැරැද්ද නොකරන්න.

එය ඔබ OAuth සපයන්නා සමඟ සත්යතාවයක් බව (පරිශීලක නාමය හා මුර පදය විසින්, කියන්න, හෝ සමහර විට SSL සේවාදායකයා certs, හෝ වෙනත් ආකාරයකින්) ඇත්ත ඇති අතර, කළ යුතු දේ සේවාදායකයාගේ ආපසු ලැබෙන නොවන අවශ්යයෙන්ම අනන්යතාව ඔප්පු ලෙස ගත. උදාහරණයක් ලෙස වෙනත් පරිශීලකයෙකුගේ සම්පත් වෙත ප්‍රවේශය ඔබට පවරා ඇති ප්‍රවාහයක් වනු ඇත (සහ ප්‍රොක්සි අනුව, OAuth සේවාදායකයා). බලය පැවරීම සත්‍යාපනය අදහස් නොකරයි.

සත්‍යාපනය හැසිරවීම සඳහා, ඔබට OAuth 2.0 විසින් පිහිටුවා ඇති අත්තිවාරමට ඉහළින් ඇති තවත් ස්ථරයක් වන OpenID Connect පිළිබඳව සොයා බැලීමට අවශ්‍ය වනු ඇත. OpenID Connect ( https://oauth.net/articles/authentication/ වෙතින්) පිළිබඳ වඩාත් වැදගත් කරුණු ග්‍රහණය කර ගන්නා (මගේ මතය අනුව) උපුටා දැක්වීමක් මෙන්න :

OpenID Connect යනු 2014 මුලදී ප්‍රකාශයට පත් කරන ලද විවෘත ප්‍රමිතියකි, එය පරිශීලක සත්‍යාපනය සිදු කිරීම සඳහා OAuth 2.0 භාවිතා කිරීමට අන්තර්ක්‍රියාකාරී ක්‍රමයක් නිර්වචනය කරයි. සාරාංශයක් ලෙස, එය චොකලට් ෆඩ්ජ් සඳහා පුළුල් ලෙස ප්‍රකාශයට පත් කරන ලද වට්ටෝරුවකි. එය පුළුල් සංඛ්‍යාවක් සහ විවිධ විශේෂ .යින් විසින් අත්හදා බලා තිබේ. එක් එක් විභව අනන්‍යතා සැපයුම්කරුට වෙනස් ප්‍රොටෝකෝලයක් තැනීම වෙනුවට, යෙදුමකට එක් ප්‍රොටෝකෝලයක් ඔවුන් සමඟ වැඩ කිරීමට අවශ්‍ය තරම් සැපයුම්කරුවන්ට කථා කළ හැකිය. එය විවෘත ප්‍රමිතියක් බැවින්, සීමාවකින් තොරව හෝ බුද්ධිමය දේපල අවශ්‍යතා නොමැතිව ඕනෑම කෙනෙකුට OpenID සම්බන්ධතාවය ක්‍රියාත්මක කළ හැකිය.

OpenID Connect සෘජුවම OAuth 2.0 මත ගොඩනගා ඇති අතර බොහෝ අවස්ථාවන්හි OAuth යටිතල ව්‍යුහයක් සමඟ (හෝ ඉහළින්) යොදවනු ලැබේ. OpenID Connect විසින් JSON Object Signing and Encryption (JOSE) විවිධ ස්ථානවල අත්සන් කරන ලද සහ සංකේතාත්මක තොරතුරු රැගෙන යාම සඳහා පිරිවිතර කට්ටලයක් භාවිතා කරයි. ඇත්ත වශයෙන්ම, JOE හැකියාවන් සහිත OAuth 2.0 යෙදවීම දැනටමත් සම්පුර්ණ අනුකූල OpenID Connect පද්ධතියක් නිර්වචනය කිරීමට බොහෝ දුරක් ඇති අතර මේ දෙක අතර ඩෙල්ටා සාපේක්ෂව කුඩා වේ. නමුත් එම ඩෙල්ටාව විශාල වෙනසක් ඇති කරයි, සහ OAuth පදනමට ප්‍රධාන කොටස් කිහිපයක් එකතු කිරීමෙන් ඉහත සාකච්ඡා කළ බොහෝ අන්තරායන් වළක්වා ගැනීමට OpenID Connect කළමනාකරණය කරයි: [...]

ලේඛනය පසුව (වෙනත් දේ අතර) ටෝකන් හැඳුනුම්පත් සහ පරිශීලක ඉන්ෆෝ එන්ඩ්පොයින්ට් විස්තර කරයි. පළමුවැන්නා හිමිකම් කට්ටලයක් සපයයි (ඔබ කවුද, ටෝකනය නිකුත් කළ විට යනාදිය, සහ සමහර විට උඩුමහලේ සේවාව විමසීමෙන් තොරව ප්‍රකාශිත පොදු යතුරක් හරහා ටෝකනයේ සත්‍යතාව තහවුරු කර ගැනීම සඳහා අත්සනක් ), සහ දෙවැන්න සපයන්නේ උදා: පරිශීලකයාගේ පළමු / අවසාන නම, ඊමේල් සහ ඒ හා සමාන තොරතුරු ඉල්ලා සිටීම, සියල්ලම ප්‍රමිතිගත ආකාරයකින් (ඕපන්අයිඩී සම්බන්ධ කිරීමට පෙර මිනිසුන් භාවිතා කළ සම්මත දේවල් OAuth වෙත තාවකාලික දීර් ensions කිරීම් වලට වෙනස්ව).

OpenId - සත්‍යාපනය සඳහා පමණක් භාවිතා වේ.

OAuth - සත්‍යාපනය සහ බලය පැවරීම යන දෙකටම භාවිතා වේ. බලය පැවරීම රඳා පවතින්නේ JWT ටෝකනයේ කොටසක් ලෙස ලැබෙන access_token මත ය. එයට පරිශීලක අවසරයන් පිළිබඳ විස්තර හෝ ප්‍රයෝජනවත් තොරතුරු තිබිය හැකිය.

දෙදෙනාම තම ගිණුම් පවත්වාගෙන යන තෙවන පාර්ශවීය සත්‍යාපන සැපයුම්කරු මත විශ්වාසය තැබිය හැකිය. උදාහරණයක් ලෙස OKTA අනන්‍යතා සැපයුම්කරු, පරිශීලකයා OKTA පිවිසුම් පිටුවේ අක්තපත්‍ර සපයන අතර සාර්ථක පිවිසුමකදී පරිශීලකයා පාරිභෝගික යෙදුම මත ශීර්ෂයේ JWT ටෝකනය සමඟ හරවා යවනු ලැබේ.

සත්‍යාපනය සමඟ කටයුතු කිරීමට OpenId OAuth භාවිතා කරයි.

ප්‍රතිසමයට අනුව, එය .NET වින්ඩෝස් API මත රඳා පවතී. ඔබට වින්ඩෝස් ඒපීඅයි වෙත කෙලින්ම ඇමතිය හැකි නමුත් එය එතරම් පුළුල්, සංකීර්ණ හා ක්‍රම තර්ක විශාල ය, ඔබට පහසුවෙන් වැරදි / දෝෂ / ආරක්ෂක ගැටළු ඇති කළ හැකිය.

OpenId / OAuth සමඟ සමාන වේ. සත්‍යාපනය කළමනාකරණය කිරීම සඳහා OpenId OAuth මත රඳා පවතින නමුත් නිශ්චිත ටෝකන් (Id_token), ඩිජිටල් අත්සන සහ විශේෂිත ප්‍රවාහයන් නිර්වචනය කරයි.

ප්රොටෝකෝල දෙකම විවිධ හේතු නිසා නිර්මාණය කරන ලදී. OAuth නිර්මාණය කරන ලද්දේ සම්පත් වෙත ප්‍රවේශ වීමට තෙවන පාර්ශවයන්ට බලය පැවරීම සඳහා ය. විමධ්‍යගත අනන්‍යතා වලංගු කිරීම සඳහා OpenID නිර්මාණය කරන ලදි. මෙම වෙබ් අඩවිය පහත සඳහන් දේ සඳහන් කරයි:

OAuth යනු අවසාන පරිශීලකයෙකුගේ අනන්‍යතාවය තහවුරු කිරීම සහ තෙවන පාර්ශවයකට අවසර ලබා දීම සඳහා නිර්මාණය කර ඇති ප්‍රොටෝකෝලයකි. මෙම සත්‍යාපනය ටෝකනයක් ලබා දෙයි. තෙවන පාර්ශවයට පරිශීලකයා වෙනුවෙන් සම්පත් වෙත ප්‍රවේශ වීමට මෙම ටෝකනය භාවිතා කළ හැකිය. ටෝකන වලට විෂය පථයක් ඇත. පරිශීලකයෙකුට සම්පතක් ප්‍රවේශ විය හැකිද නැද්ද යන්න තහවුරු කර ගැනීම සඳහා විෂය පථය භාවිතා කරයි

OpenID යනු විමධ්‍යගත සත්‍යාපනය සඳහා භාවිතා කරන ප්‍රොටෝකෝලයකි. සත්‍යාපනය යනු අනන්‍යතාවය පිළිබඳ ය; පරිශීලකයා ස්ථාපනය කිරීම ඇත්ත වශයෙන්ම ඔහු යැයි කියා ගන්නා පුද්ගලයා වේ. එය විමධ්‍යගත කිරීම යන්නෙන් අදහස් වන්නේ ආරක්ෂා කිරීමට අවශ්‍ය සම්පත් හෝ යෙදුම්වල පැවැත්ම මෙම සේවාව නොදන්නා බවයි. OAuth සහ OpenID අතර ඇති ප්‍රධාන වෙනස එයයි.

OpenID Connect මඟින් OAuth 2.0 බලය පැවරීමේ ප්‍රොටෝකෝලය සත්‍යාපන ප්‍රොටෝකෝලයක් ලෙස භාවිතා කරයි, එවිට ඔබට OAuth භාවිතා කර තනි පුරනය වීමක් කළ හැකිය. OpenID Connect විසින් ID ටෝකනයක සංකල්පය හඳුන්වා දෙයි, එය ආරක්ෂක ටෝකනයක් වන අතර එමඟින් පරිශීලකයාගේ අනන්‍යතාවය සත්‍යාපනය කිරීමට සේවාදායකයාට ඉඩ ලබා දේ

සම්පත් සේවාදායකයෙන් සම්පත වෙත ප්‍රවේශ වීම සඳහා OAuth ඔබට ප්‍රවේශ ටෝකනය ආපසු ලබා දෙයි, OpenW ඔබට JWT / සංකේතාත්මක ටෝකනයේ සම්පත් පිළිබඳ මෙටා දත්ත විස්තර ලබා දෙයි.

OAuth 2.0 යනු ආරක්ෂක ප්‍රොටෝකෝලයකි. එය සත්‍යාපනය කිරීම හෝ බලය පැවරීමේ ප්‍රොටෝකෝලයක් නොවේ.

නිර්වචනය අනුව සත්‍යාපනය ප්‍රශ්න දෙකකට පිළිතුරු සපයයි.

1. පරිශීලකයා කවුද?
2. පරිශීලකයා දැනට පද්ධතියේ සිටීද?

OAuth 2.0 හි පහත දැක්වෙන ප්‍රදාන වර්ග තිබේ

• client_credentials: එක් යෙදුමකට තවත් යෙදුමක් සමඟ අන්තර් ක්‍රියා කිරීමට සහ බහු පරිශීලකයින්ගේ දත්ත වෙනස් කිරීමට අවශ්‍ය වූ විට.
• Authorization_code: ආරක්ෂිත සම්පතකට ප්‍රවේශ වීම සඳහා සේවාදායකයාට භාවිතා කළ හැකි ප්‍රවේශ_ ටෝකනයක් නිකුත් කිරීම සඳහා පරිශීලක බලය පැවරීමේ සේවාදායකය පවරයි.
• refresh_token: access_token කල් ඉකුත් වූ විට, නැවුම් ප්‍රවේශයක් ලබා ගැනීම සඳහා නැවුම් ටෝකනය උත්තේජනය කළ හැකිය
• මුරපදය: පරිශීලකයා ඔවුන්ගේ පිවිසුම් අක්තපත්‍ර සේවාදායකයාට ලබා දී ඇති අතර එය බලය පැවරීමේ සේවාදායකයා අමතා ප්‍රවේශ_ටෝකන් ලබා ගනී

ආරක්ෂිත සම්පත් වෙත ප්‍රවේශ වීම සඳහා භාවිතා කළ හැකි පුරාවස්තුවක් වන 4 දෙනාටම එක දෙයක් තිබේ, access_token.

"සත්‍යාපන" ප්‍රොටෝකෝලයක් විසින් පිළිතුරු සැපයිය යුතු ප්‍රශ්න 2 ට ප්‍රවේශය access_token සපයන්නේ නැත.

Oauth 2.0 පැහැදිලි කිරීම සඳහා උදාහරණයක් (බැර: OAuth 2 in Action, Manning ප්‍රකාශන)

අපි චොකලට් ගැන කතා කරමු. ෆඩ්ජ්, අයිස්ක්‍රීම් සහ කේක් ඇතුළු චොකලට් වලින් අපට බොහෝ රසකැවිලි සෑදිය හැකිය. එහෙත්, මේ කිසිවක් චොකලට් වලට සමාන කළ නොහැක. මන්දයත් රසකැවිලි සෑදීම සඳහා ක්‍රීම් සහ පාන් වැනි තවත් අමුද්‍රව්‍ය කිහිපයක් අවශ්‍ය වන නමුත් චොකලට් ප්‍රධාන අමුද්‍රව්‍යය ලෙස පෙනුනද. ඒ හා සමානව, OAuth 2.0 යනු චොකලට් වන අතර කුකීස්, ටීඑල්එස් යටිතල පහසුකම්, හැඳුනුම්පත් සපයන්නන් යනු “සත්‍යාපනය” ක්‍රියාකාරීත්වය සැපයීමට අවශ්‍ය අනෙකුත් අමුද්‍රව්‍ය වේ.

ඔබට සත්‍යාපනය අවශ්‍ය නම්, සෑම සත්‍යාපන ප්‍රොටෝකෝලයක්ම පිළිතුරු දිය යුතු ප්‍රශ්න වලට පිළිතුරු සපයන ප්‍රවේශ_ටෝකනයකට අමතරව “id_token” සපයන OpenID Connect සඳහා ඔබට යා හැකිය.

OAuth අවසරය මත සත්‍යාපනය ගොඩනඟයි: පරිශීලකයා ඔවුන්ගේ අනන්‍යතාවයට ප්‍රවේශයට යෙදුම වෙත පවරන අතර, එමඟින් අනන්‍යතා API හි පාරිභෝගිකයෙකු බවට පත්වන අතර එමඟින් සේවාදායකයාට මුලින් අවසර දුන්නේ කවුදැයි සොයා ගනී http://oauth.net/ ලිපි / සත්‍යාපනය /