આર્કિટેક્ચર નિર્ણય રેકોર્ડ: ઓથેન્ટિકેશન અને ઓથોરાઇઝેશનના વિકલ્પો

વેબ એપ્લિકેશન ઓથેન્ટિકેશન અને ઓથોરાઇઝેશન એપ્લિકેશનો અને સેવાઓની ઍક્સેસ સુરક્ષિત કરવા માટેના બે નિર્ણાયક ખ્યાલો છે. બંને વપરાશકર્તાઓની ઓળખ અને પરવાનગીઓ કેવી રીતે આપવામાં આવે છે તે સાથે સંબંધિત છે, પરંતુ તેઓ જુદા જુદા પાસાં પર ધ્યાન કેન્દ્રિત કરે છે:

ઓથેન્ટિકેશન વપરાશકર્તા અથવા સિસ્ટમની ઓળખ ચકાસવાની પ્રક્રિયા છે.
ઓથોરાઇઝેશન એ નક્કી કરવાની પ્રક્રિયા છે કે ઓથેન્ટિકેટ થયેલો વપરાશકર્તા કે સિસ્ટમ કયા સંસાધનો કે કાર્યવાહીઓ સુધી પહોંચી શકે.

હવે, ચાલો તમે ઉલ્લેખેલા ચોક્કસ પ્રોટોકોલ અને ટેકનોલોજીમાં ઊંડા ઉતરીએ, જે આધુનિક વેબ એપ્લિકેશનોમાં ઓથેન્ટિકેશન અને ઓથોરાઇઝેશનનું સંચાલન કરવા માટે સામાન્ય રીતે વપરાય છે.

1. OAuth (Open Authorization)

OAuth ઓથોરાઇઝેશન માટેનું ખુલ્લું ધોરણ છે. તે વપરાશકર્તાને તૃતીય-પક્ષ એપ્લિકેશનને તેમના સંસાધનોની મર્યાદિત ઍક્સેસ આપવા દે છે, તેમના ઓળખપત્રો વહેંચ્યા વિના. મુખ્ય વિચાર પ્રતિનિધિ ઍક્સેસ છે. OAuth ઘણીવાર એવી પરિસ્થિતિઓમાં વપરાય છે જ્યાં વપરાશકર્તાઓ તૃતીય-પક્ષ સેવામાં લૉગ ઇન કરી શકે (દા.ત., Google સાથે સાઇન ઇન કરવું) તૃતીય-પક્ષને સીધા પોતાનું વપરાશકર્તા નામ અને પાસવર્ડ આપ્યા વિના.

પ્રવાહ: OAuth સામાન્ય રીતે ટોકન-આધારિત પ્રવાહ અનુસરે છે, જ્યાં ઓથોરાઇઝેશન સર્વર તૃતીય-પક્ષ એપ્લિકેશનને ઍક્સેસ ટોકન જારી કરે છે. આ ટોકન વપરાશકર્તાની પરવાનગીઓનું પ્રતિનિધિત્વ કરે છે, અને એપ્લિકેશન તેનો ઉપયોગ API માંથી વપરાશકર્તાના ડેટા કે સંસાધનો ઍક્સેસ કરવા માટે કરે છે.
ઉદાહરણ: વપરાશકર્તા તેમના Google ખાતા વડે તૃતીય-પક્ષ એપ્લિકેશનમાં સાઇન ઇન કરે છે. Google વપરાશકર્તાની ઓળખ ચકાસે છે અને પછી ટોકન આપે છે જે તૃતીય-પક્ષ એપ્લિકેશનને કેટલાક Google ડેટા (દા.ત., Google Calendar) ઍક્સેસ કરવા દે છે.

OAuth ઓથેન્ટિકેશનને સીધું સંભાળતું નથી; તે ઍક્સેસ આપવા વિશે છે. ઓથેન્ટિકેશન માટે, OAuth ઘણીવાર અન્ય પ્રોટોકોલ, જેમ કે OpenID Connect, સાથે જોડાય છે.

2. OpenID Connect (OIDC)

OpenID Connect (OIDC) એ OAuth 2.0 ની ઉપર બનેલું ઓળખ સ્તર છે જે OAuth ની ઓથોરાઇઝેશન ક્ષમતાઓમાં ઓથેન્ટિકેશન ઉમેરે છે. મૂળભૂત રીતે, OpenID Connect OAuth ને વપરાશકર્તા ઓથેન્ટિકેશન સંભાળવા માટે વિસ્તારે છે અને એપ્લિકેશનોને વપરાશકર્તાની ઓળખ ચકાસવાની પ્રમાણિત રીત આપે છે.

પ્રવાહ: જ્યારે વપરાશકર્તા OpenID Connect વાપરીને લૉગ ઇન કરે છે, ત્યારે તૃતીય-પક્ષ એપ્લિકેશન ID ટોકન માગે છે (OAuth ઍક્સેસ ટોકન ઉપરાંત). ID ટોકનમાં વપરાશકર્તા વિશેની માહિતી હોય છે (જેમ કે તેમનું વપરાશકર્તા નામ, ઇમેઇલ અને અન્ય દાવાઓ). આ એપ્લિકેશનને જાણવા દે છે કે વપરાશકર્તા કોણ છે અને તે ઓથેન્ટિકેટ થયેલ છે કે નહીં.
ઉદાહરણ: Slack જેવી સેવામાં તમારા Google ખાતા વડે લૉગ ઇન કરવું (Google OpenID Connect પ્રદાતા હોવાથી) માં OpenID Connect દ્વારા ઓથેન્ટિકેશન શામેલ છે, જ્યારે OAuth તમારા Google સંસાધનોની ઍક્સેસનું સંચાલન કરે છે.

OIDC તૃતીય-પક્ષ એપ્લિકેશનો માટે વપરાશકર્તાઓને ઓથેન્ટિકેટ કરવાનું સરળ બનાવે છે અને તે એપ્લિકેશનો કયા સંસાધનો ઍક્સેસ કરી શકે તેના પર બારીક નિયંત્રણ પણ જાળવે છે.

3. SAML (Security Assertion Markup Language)

SAML એ જૂનું, XML-આધારિત ધોરણ છે જે પક્ષો વચ્ચે ઓથેન્ટિકેશન અને ઓથોરાઇઝેશન ડેટાની આપ-લે માટે વપરાય છે, ખાસ કરીને Single Sign-On (SSO) પરિસ્થિતિઓમાં. તે મુખ્યત્વે એન્ટરપ્રાઇઝ વાતાવરણમાં વપરાય છે જેથી વપરાશકર્તાઓ એકવાર ઓથેન્ટિકેટ થઈને ઓળખપત્રો ફરી દાખલ કર્યા વિના અનેક એપ્લિકેશનો ઍક્સેસ કરી શકે.

પ્રવાહ: વપરાશકર્તા પહેલા ઓળખ પ્રદાતા (IdP) સાથે ઓથેન્ટિકેટ થાય છે. IdP હસ્તાક્ષરિત SAML દાવો બનાવે છે જેમાં વપરાશકર્તાની ઓળખ અને સંબંધિત લક્ષણો હોય છે. દાવો સેવા પ્રદાતા (SP) ને મોકલાય છે, જે તેનો ઉપયોગ એપ્લિકેશનની ઍક્સેસ અધિકૃત કરવા માટે કરે છે.
ઉદાહરણ: કર્મચારી તેમના કોર્પોરેટ પોર્ટલ (IdP) માં લૉગ ઇન કરે છે અને ઓળખપત્રો ફરી દાખલ કર્યા વિના આપમેળે ઇમેઇલ, CRM, વગેરે જેવી અન્ય સિસ્ટમોમાં લૉગ ઇન થઈ જાય છે. ઓથેન્ટિકેશન પ્રક્રિયા IdP દ્વારા મોકલાયેલા SAML દાવા પર આધારિત છે.

SAML સામાન્ય રીતે એન્ટરપ્રાઇઝ SSO ઉકેલો માં વપરાય છે અને કોર્પોરેટ વાતાવરણમાં વેબ એપ્લિકેશનો માટે સારી રીતે કામ કરે છે, પરંતુ OAuth/OIDC ની સરખામણીમાં તે ઓછું મોબાઇલ-અનુકૂળ છે.

4. WS-Federation (Web Services Federation)

WS-Federation એ Single Sign-On (SSO) માટે વપરાતો બીજો પ્રોટોકોલ છે, ખાસ કરીને Microsoft-આધારિત એન્ટરપ્રાઇઝ વાતાવરણમાં. તે WS- (Web Services)* સ્પષ્ટીકરણોના પરિવારનો ભાગ છે અને વિવિધ સુરક્ષા ડોમેનો (જેમ કે વિવિધ સંસ્થાઓ વચ્ચે કે વિવિધ સેવાઓ વચ્ચે) માં ઓળખ સંઘ શક્ય બનાવે છે.

પ્રવાહ: WS-Federation વિશ્વસનીય ઓળખ પ્રદાતા (IdP) ને વપરાશકર્તાઓને ઓથેન્ટિકેટ કરવા અને સેવા પ્રદાતા ઓથોરાઇઝેશન માટે વાપરી શકે તેવા ટોકન જારી કરવા દે છે. તે SAML જેવું જ છે પરંતુ ઘણીવાર Microsoft ટેકનોલોજી પર ભારે આધાર રાખતી પરિસ્થિતિઓમાં વપરાય છે.
ઉદાહરણ: વપરાશકર્તા Microsoft Azure Active Directory (AD) દ્વારા હોસ્ટ કરેલી એન્ટરપ્રાઇઝ એપ્લિકેશનમાં લૉગ ઇન કરે છે, અને તેમની ઓળખ અન્ય સંઘીય સેવાઓ, તૃતીય-પક્ષ વિક્રેતાઓ દ્વારા હોસ્ટ કરેલી એપ્લિકેશનો સહિત, ઍક્સેસ કરવા માટે વાપરી શકાય છે.

જોકે ઘણા આધુનિક વેબ વાતાવરણમાં WS-Federation ને મોટાભાગે OAuth2.0 અને OpenID Connect જેવા નવા પ્રોટોકોલોએ બદલી નાખ્યું છે, તે હજુ પણ જૂની સિસ્ટમોમાં વપરાય છે, ખાસ કરીને Microsoft-કેન્દ્રિત એન્ટરપ્રાઇઝમાં.

5. LDAP (Lightweight Directory Access Protocol)

LDAP એ ડિરેક્ટરી સેવાઓ ઍક્સેસ કરવા અને સંચાલિત કરવા માટે વપરાતો પ્રોટોકોલ છે, જે સામાન્ય રીતે વપરાશકર્તા ઓળખપત્રો સંગ્રહવા અને કેન્દ્રિય ડિરેક્ટરી (ઘણીવાર Directory Service કહેવાય) માં ઍક્સેસ નિયંત્રણનું સંચાલન કરવા માટે વપરાય છે. LDAP ખાસ કરીને ઓથેન્ટિકેશન કે ઓથોરાઇઝેશન વિશે નથી પરંતુ ઓળખ ડેટા સંગ્રહવા અને પુનઃપ્રાપ્ત કરવા માટે વપરાય છે, જે પછી તે પ્રક્રિયાઓમાં વપરાય છે.

ઓથેન્ટિકેશન: LDAP એપ્લિકેશનને ડિરેક્ટરી સેવાને ઓળખપત્રો (જેમ કે પાસવર્ડ) માટે પૂછીને વપરાશકર્તાઓને ઓથેન્ટિકેટ કરવા દે છે.
ઓથોરાઇઝેશન: તે વપરાશકર્તાની ભૂમિકાઓ અને પરવાનગીઓનું પણ સંચાલન કરે છે, વપરાશકર્તાને અમુક સંસાધનોની ઍક્સેસ છે કે નહીં તે નક્કી કરવામાં મદદ કરે છે.
ઉદાહરણ: ઘણા એન્ટરપ્રાઇઝ ઓથેન્ટિકેશન અને ઓથોરાઇઝેશન માટે LDAP-આધારિત ડિરેક્ટરીઓ (દા.ત., Active Directory) વાપરે છે, ખાસ કરીને Windows વાતાવરણમાં.

આંતરિક સિસ્ટમોમાં વપરાશકર્તા ઍક્સેસનું સંચાલન કરવા માટે એન્ટરપ્રાઇઝ માટે LDAP નિર્ણાયક છે, પરંતુ આધુનિક વેબ સંદર્ભમાં, વધુ સંપૂર્ણ ઓળખ વ્યવસ્થાપન માટે LDAP ને ઘણીવાર SAML કે OAuth જેવા અન્ય પ્રોટોકોલ સાથે ઇન્ટિગ્રેટ કરવામાં આવે છે.

6. સોશિયલ SSO પ્રદાતાઓ

Facebook, Google, Twitter, GitHub અને અન્ય જેવા સોશિયલ Single Sign-On (SSO) પ્રદાતાઓ વપરાશકર્તાઓને તેમના સોશિયલ મીડિયા ઓળખપત્રો વાપરીને તૃતીય-પક્ષ એપ્લિકેશનોમાં ઓથેન્ટિકેટ થવા દે છે. આ એક પ્રકારનું OAuth-આધારિત ઓથેન્ટિકેશન છે જ્યાં તૃતીય-પક્ષ સેવા (દા.ત., Google) ઓળખ પ્રદાતા છે.

પ્રવાહ: વપરાશકર્તા "Google સાથે લૉગ ઇન કરો" (ઉદાહરણ તરીકે) પર ક્લિક કરે છે. એપ્લિકેશન Google પર રીડાયરેક્ટ કરે છે, જ્યાં વપરાશકર્તા લૉગ ઇન કરે છે (જો પહેલેથી લૉગ ઇન ન હોય). Google પછી તૃતીય-પક્ષ એપ્લિકેશનને ઍક્સેસ ટોકન અથવા ID ટોકન આપે છે, જેનો ઉપયોગ વપરાશકર્તાને ઓથેન્ટિકેટ કરવા અને સંભવતઃ તેમના ડેટાની ઍક્સેસ માટે થઈ શકે.
ઉદાહરણ: ઘણી એપ્લિકેશનો તમને તમારા Google કે Facebook ઓળખપત્રો વડે લૉગ ઇન કરવા દે છે. એપ્લિકેશન પડદા પાછળ તમારી ઓળખ ચકાસવા અને, કેટલાક કિસ્સામાં, અમુક સોશિયલ મીડિયા ડેટા ઍક્સેસ કરવા માટે OAuth કે OpenID Connect વાપરશે.

સોશિયલ SSO ઓથેન્ટિકેશન માટે સગવડભરી અને વ્યાપકપણે અપનાવાયેલી પદ્ધતિ છે કારણ કે તે વપરાશકર્તાઓ માટે અવરોધ ઘટાડે છે, જેઓ કદાચ બીજું વપરાશકર્તા નામ અને પાસવર્ડ બનાવવા માગતા ન હોય.

તફાવતોનો સારાંશ:

OAuth: ઓથોરાઇઝેશન માટે વપરાય છે, તૃતીય-પક્ષ એપ્લિકેશનોને ઓળખપત્રો ઉજાગર કર્યા વિના વપરાશકર્તા ડેટા ઍક્સેસ કરવા દે છે.
OpenID Connect: ઓથેન્ટિકેશન પૂરું પાડવા OAuth ને વિસ્તારે છે, એપ્લિકેશનોને વપરાશકર્તાની ઓળખ ચકાસવા સક્ષમ બનાવે છે.
SAML: SSO માટે વપરાતો XML-આધારિત પ્રોટોકોલ, ઘણીવાર એન્ટરપ્રાઇઝ વાતાવરણમાં.
WS-Federation: ઓળખ સંઘ માટેનો Microsoft-વિશિષ્ટ પ્રોટોકોલ, જૂની સિસ્ટમોમાં વપરાય છે.
LDAP: વપરાશકર્તાઓને ઓથેન્ટિકેટ કરવા અને ઓથોરાઇઝેશન સંચાલિત કરવા ડિરેક્ટરી સેવાઓને પૂછવા માટેનો પ્રોટોકોલ.
સોશિયલ SSO પ્રદાતાઓ: OAuth-આધારિત સિસ્ટમો (જેમ કે Google, Facebook) જે તૃતીય-પક્ષ એપ્લિકેશનોને તેમના સોશિયલ મીડિયા ઓળખપત્રો વાપરીને વપરાશકર્તાઓને ઓથેન્ટિકેટ કરવા દે છે.

આ દરેક ટેકનોલોજીની પોતાની શક્તિઓ અને ઉપયોગ કેસ છે, અને આધુનિક એપ્લિકેશનોમાં, તમે સુરક્ષાના વિવિધ પાસાં માટે (દા.ત., API ઍક્સેસ માટે OAuth/OIDC, એન્ટરપ્રાઇઝ SSO માટે SAML) તેમનું સંયોજન વપરાતું જોઈ શકો છો.