OAuth എന്താണ്? "Google ഉപയോഗിച്ച് സൈൻ ഇൻ", ഡെലിഗേറ്റഡ് ആക്സസ് വിശദീകരണം

OAuth ഒരു തുറന്ന സ്റ്റാൻഡേർഡ് ആണ്; ഒരു ഉപയോക്താവിന് തന്റെ പാസ്‌വേഡ് കൈമാറാതെ, മറ്റൊരു സേവനത്തിലെ തന്റെ അക്കൗണ്ടിലേക്ക് ഒരു ആപ്പിന് പരിമിതമായ ആക്സസ് നൽകാൻ ഇത് അനുവദിക്കുന്നു. “Connect Google Calendar” ക്ലിക്ക് ചെയ്യുമ്പോൾ “ഈ ആപ്പിന് നിങ്ങളുടെ ഇവന്റുകൾ കാണാൻ അനുവദിക്കണോ?” എന്ന സ്‌ക്രീൻ വരുന്നത് OAuth ആണ്. നിങ്ങൾ അംഗീകരിച്ചതിന് മാത്രമുള്ള ഒരു ടോക്കൺ ആപ്പിന് കിട്ടുന്നു; അത് എപ്പോൾ വേണമെങ്കിലും റദ്ദാക്കാം. OpenID Connect എന്ന അധിക പാളിയോടൊപ്പം ഇതേ സംവിധാനമാണ് “Sign in with Google” പോലുള്ള ബട്ടണുകളെ ശക്തിപ്പെടുത്തുന്നത്.

AI ഉപയോഗിച്ച് നിർമ്മിക്കുമ്പോൾ OAuth പ്രധാനമാകുന്നത് എന്തുകൊണ്ട്

ഒരു ആപ്പ് നിർമ്മിക്കുമ്പോൾ OAuth രണ്ട് സാഹചര്യങ്ങളിൽ വരുന്നു:

1. സോഷ്യൽ ലോഗിൻ. നിങ്ങളുടെ ഉപയോക്താക്കൾ മറ്റൊരു പാസ്‌വേഡ് ഉണ്ടാക്കുന്നതിന് പകരം “Sign in with Google” (അല്ലെങ്കിൽ Apple, Microsoft, GitHub) ഉപയോഗിക്കണമെന്ന് ആഗ്രഹിക്കുന്നു. നിങ്ങളുടെ ആപ്പിൽ ലോഗിൻ ചേർക്കുന്നത് എങ്ങനെ കാണുക.
2. മറ്റ് സേവനങ്ങളിലെ ഉപയോക്താക്കളുടെ അക്കൗണ്ടുകളുമായി ബന്ധിപ്പിക്കൽ. നിങ്ങളുടെ ആപ്പിന് ഒരു ഉപയോക്താവിന്റെ കലണ്ടർ വായിക്കണം, അവരുടെ സോഷ്യൽ അക്കൗണ്ടിൽ പോസ്റ്റ് ചെയ്യണം, ക്ലൗഡ് ഡ്രൈവിൽ നിന്ന് ഫയലുകൾ എടുക്കണം, അല്ലെങ്കിൽ അക്കൗണ്ടിംഗ് ഡാറ്റ സിങ്ക് ചെയ്യണം.

രണ്ട് സാഹചര്യങ്ങളിലും നിങ്ങളുടെ AI ബിൽഡർ കോഡ് എഴുതിത്തരും, പക്ഷേ ചില ഘട്ടങ്ങൾ നിങ്ങൾക്ക് മാത്രം ചെയ്യാനാകും: ദാതാവിനൊപ്പം ഒരു ഡെവലപ്പർ ആപ്പ് സൃഷ്ടിക്കൽ, client ID, client secret എന്നിവ നേടൽ, കോൾബാക്ക് URL-കൾ രജിസ്റ്റർ ചെയ്യൽ, ചില അനുമതികൾക്ക് ദാതാവിന്റെ അവലോകനം പാസാകൽ. OAuth എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്ന് അറിഞ്ഞാൽ ആ ഘട്ടങ്ങളും അവ ഉണ്ടാക്കുന്ന പിശകുകളും അത്ര നിഗൂഢമായി തോന്നില്ല. ലോഗിന്റെ വലിയ ചിത്രത്തിന് ഓതന്റിക്കേഷൻ എന്താണ് കാണുക.

ഒരു ദൈനംദിന ഉദാഹരണം

ഒരു ഹോട്ടൽ കീ കാർഡ് സങ്കൽപ്പിക്കുക. ചെക്ക്-ഇന്നിൽ റിസപ്ഷൻ നിങ്ങൾ ആരാണെന്ന് ഉറപ്പാക്കുന്നു, പിന്നെ നിങ്ങളുടെ മുറിയും ജിമ്മും തുറക്കുന്ന ഒരു കാർഡ് നൽകുന്നു — മറ്റ് മുറികളോ സ്റ്റാഫ് ഏരിയകളോ അല്ല — ചെക്ക്-ഔട്ടിൽ പ്രവർത്തനം നിൽക്കുകയും ചെയ്യുന്നു. കാർഡിൽ നിങ്ങളുടെ പാസ്‌പോർട്ട് ഇല്ല. കാർഡ് നഷ്ടപ്പെട്ടാൽ റിസപ്ഷൻ അത് റദ്ദാക്കി പുതിയത് നൽകുന്നു.

• റിസപ്ഷൻ ആണ് ഓതറൈസേഷൻ സെർവർ (Google-ന്റെ സൈൻ-ഇൻ പേജ്).
• നിങ്ങളുടെ ഐഡി പരിശോധന ആണ് Google-ൽ നിങ്ങൾ സൈൻ ഇൻ ചെയ്യുന്നത്.
• കീ കാർഡ് ആണ് ആക്സസ് ടോക്കൺ.
• “മുറിയും ജിമ്മും മാത്രം” എന്നത് നിങ്ങൾ അംഗീകരിച്ച സ്കോപ്പുകൾ.
• ചെക്ക്-ഔട്ട് എന്നത് ടോക്കൺ കാലഹരണപ്പെടുന്നത്, അല്ലെങ്കിൽ നിങ്ങൾ ആക്സസ് റദ്ദാക്കുന്നത്.

നിങ്ങൾ ഉപയോഗിക്കുന്ന ആപ്പ് ഒരിക്കലും നിങ്ങളുടെ Google പാസ്‌വേഡ് കാണുന്നില്ല, കീ കാർഡ് മാത്രം.

OAuth ഘട്ടം ഘട്ടമായി പ്രവർത്തിക്കുന്ന വിധം

വെബ് ആപ്പുകൾക്ക് ഏറ്റവും സാധാരണമായ ഫ്ലോ authorization code flow ആണ്. ഒരു ഉപയോക്താവ് തന്റെ Google Calendar ഒരു ഷെഡ്യൂളിംഗ് ആപ്പുമായി ബന്ധിപ്പിക്കുമ്പോൾ ഇതാണ് നടക്കുന്നത്:

1. ക്ലിക്ക്. ഉപയോക്താവ് “Connect Google Calendar” ക്ലിക്ക് ചെയ്യുന്നു.
2. ദാതാവിലേക്ക് റീഡയറക്ട്. ആപ്പ് ബ്രൗസറിനെ അതിന്റെ client ID, ആവശ്യമുള്ള സ്കോപ്പുകൾ (കലണ്ടർ ഇവന്റുകൾ വായിക്കൽ), Google ഉപയോക്താവിനെ തിരികെ അയക്കേണ്ട redirect URI എന്നിവയോടെ Google-ലേക്ക് അയക്കുന്നു.
3. ലോഗിൻ ചെയ്ത് സമ്മതം. ഉപയോക്താവ് (ഇതുവരെ ചെയ്തിട്ടില്ലെങ്കിൽ) Google-ൽ സൈൻ ഇൻ ചെയ്യുന്നു; ആപ്പ് ആവശ്യപ്പെടുന്നതെല്ലാം പട്ടികപ്പെടുത്തിയ ഒരു സമ്മത സ്‌ക്രീൻ കാണുന്നു. Allow ക്ലിക്ക് ചെയ്യുന്നു.
4. ഒരു കോഡുമായി തിരികെ. Google ബ്രൗസറിനെ ആപ്പിന്റെ redirect URI-ലേക്ക് ഹ്രസ്വകാലമുള്ള, ഒരു തവണ മാത്രം ഉപയോഗിക്കാവുന്ന authorization code സഹിതം തിരികെ അയക്കുന്നു.
5. സെർവറിൽ കൈമാറ്റം. ആപ്പിന്റെ സെർവർ ആ കോഡും അതിന്റെ client secret-ഉം നേരിട്ട് Google-ന് അയച്ച് ഒരു access token (പലപ്പോഴും ഒരു refresh token-ഉം) സ്വീകരിക്കുന്നു.
6. API ഉപയോഗിക്കൽ. സെർവർ ആക്സസ് ടോക്കൺ ഉപയോഗിച്ച് Google Calendar API വിളിച്ച് ഉപയോക്താവിന്റെ ഇവന്റുകൾ എടുക്കുന്നു.

ഘട്ടം 4-ലെ കോൾബാക്ക് ഇതുപോലെയാണ്:

https://yourapp.com/auth/google/callback?code=4/0Adeu5B...&state=x7Kq9

ഘട്ടം 5-ലെ ടോക്കൺ റെസ്പോൺസ് ഇതുപോലുള്ള JSON ആണ്:

{
  "access_token": "ya29.a0Af...",
  "expires_in": 3599,
  "refresh_token": "1//0gL...",
  "scope": "https://www.googleapis.com/auth/calendar.readonly",
  "token_type": "Bearer"
}

പ്രധാനപ്പെട്ട ഡിസൈൻ പോയിന്റ്: ടോക്കൺ കൈമാറ്റം സെർവർ-ടു-സെർവർ ആയതിനാൽ client secret-ഉം ടോക്കണുകളും ബ്രൗസറിലൂടെ കടന്നുപോകേണ്ടതില്ല.

OAuth vs OpenID Connect vs നിങ്ങളുടെ സ്വന്തം ലോഗിൻ

പല ആപ്പുകളും ഇവ കൂട്ടിച്ചേർക്കുന്നു: ഇമെയിൽ-പാസ്‌വേഡ് ലോഗിൻ, OIDC വഴി “Sign in with Google”, മറ്റ് സേവനങ്ങളിലേക്കുള്ള പ്രത്യേക OAuth കണക്ഷനുകൾ.

പ്രധാന പദങ്ങൾ

സാധാരണ തെറ്റിദ്ധാരണകൾ

• “OAuth ഒരു ലോഗിൻ സിസ്റ്റമാണ്.” സാധാരണ OAuth ആക്സസ് നൽകുന്നു; ഐഡന്റിറ്റി കൈകാര്യം ചെയ്യുന്നത് OpenID Connect ആണ്. ഒരു ആക്സസ് ടോക്കൺ മാത്രം ആരാണെന്നതിന്റെ തെളിവായി ഉപയോഗിക്കുന്നത് യഥാർത്ഥ സുരക്ഷാ ബഗുകൾക്ക് കാരണമായിട്ടുണ്ട്.
• “ആപ്പ് എന്റെ പാസ്‌വേഡ് കാണുന്നു.” ഇല്ല. അതാണ് കാര്യം.
• “കൂടുതൽ സ്കോപ്പുകൾ ചോദിക്കുന്നത് ദോഷമില്ലാത്തതാണ്.” വിശാലമായ ആവശ്യങ്ങളിൽ ഉപയോക്താക്കൾ കൂടുതൽ ജാഗ്രത കാണിക്കുന്നു; Google പോലുള്ള ദാതാക്കൾ സെൻസിറ്റീവ് അല്ലെങ്കിൽ നിയന്ത്രിത സ്കോപ്പുകൾക്ക് ആപ്പ് അവലോകനം ആവശ്യപ്പെട്ടേക്കാം. ആവശ്യമുള്ളത് മാത്രം ചോദിക്കുക.
• “client secret ഫ്രണ്ടെൻഡിൽ വെക്കാം.” ബ്രൗസർ കോഡിലുള്ളതെല്ലാം പരസ്യമാണ്. അത് സെർവർ-സൈഡ് രഹസ്യങ്ങളിൽ സൂക്ഷിക്കുക.
• “ടെസ്റ്റിംഗിൽ പ്രവർത്തിക്കുന്നു, അതുകൊണ്ട് പ്രൊഡക്ഷനിലും പ്രവർത്തിക്കും.” പരിശോധിക്കപ്പെടാത്ത ആപ്പുകളെ ദാതാക്കൾ പലപ്പോഴും പരിമിതപ്പെടുത്തും — ഉദാഹരണത്തിന് പട്ടികയിലുള്ള ടെസ്റ്റ് ഉപയോക്താക്കളിലേക്ക് മാത്രം. നിങ്ങളുടെ ലൈവ് ഡൊമെയ്‌നിനുള്ള റീഡയറക്ട് URI പ്രത്യേകം രജിസ്റ്റർ ചെയ്യണം.
• “ടോക്കണുകൾ എന്നും നിലനിൽക്കും.” ആക്സസ് ടോക്കണുകൾ വേഗം കാലഹരണപ്പെടുന്നു, ഉപയോക്താക്കൾക്ക് ആക്സസ് റദ്ദാക്കാനും കഴിയും. ഇതെല്ലാം നിങ്ങളുടെ ആപ്പ് ഭംഗിയായി കൈകാര്യം ചെയ്യണം.

നിങ്ങളുടെ AI ബിൽഡറോട് എന്ത് ചോദിക്കണം

• “നന്നായി പരിപാലിക്കപ്പെടുന്ന ഒരു ഓതന്റിക്കേഷൻ ലൈബ്രറി ഉപയോഗിച്ച് OpenID Connect വഴി ‘Google ഉപയോഗിച്ച് സൈൻ ഇൻ’ ചേർക്കൂ — OAuth ഫ്ലോ സ്വയം എഴുതരുത്.”
• “PKCE ഉള്ള authorization code ഫ്ലോ ഉപയോഗിക്കൂ, state പാരാമീറ്റർ പരിശോധിക്കൂ.”
• “Client ID-യും client secret-ഉം സെർവറിലെ എൻവയോൺമെന്റ് വേരിയബിളുകളിൽ നിന്ന് വായിക്കൂ.”
• “ആവശ്യമുള്ള സ്കോപ്പുകൾ മാത്രം ചോദിക്കൂ: വായന മാത്രമുള്ള കലണ്ടർ ആക്സസ്.”
• “ദാതാവിന്റെ കൺസോളിൽ രജിസ്റ്റർ ചെയ്യേണ്ട എല്ലാ റീഡയറക്ട് URL-കളും പറയൂ — പ്രിവ്യൂവിനും പ്രസിദ്ധീകരിച്ച URL-നും എന്റെ കസ്റ്റം ഡൊമെയ്‌നിനും.”
• “റിഫ്രഷ് ടോക്കണുകൾ ഡാറ്റാബേസിൽ എൻക്രിപ്റ്റ് ചെയ്ത് സൂക്ഷിക്കൂ; കാലഹരണപ്പെട്ടതോ റദ്ദാക്കിയതോ ആയ ടോക്കണുകൾ ഉപയോക്താവിനോട് വീണ്ടും കണക്ട് ചെയ്യാൻ ആവശ്യപ്പെട്ട് കൈകാര്യം ചെയ്യൂ.”
• “ഉപയോക്താക്കൾക്ക് അവരുടെ സെറ്റിംഗ്‌സ് പേജിൽ നിന്ന് ഇന്റഗ്രേഷൻ വിച്ഛേദിക്കാൻ അനുവദിക്കൂ.”

OAuth-ഉം Mythex-ഉം

Mythex-ന് നിങ്ങൾ നിർമ്മിക്കുന്ന ആപ്പുകൾക്കായി ബിൽറ്റ്-ഇൻ എൻഡ് യൂസർ ലോഗിൻ ഇല്ല; ഡോക്‌സ് വിവരിക്കുന്നത് സ്വന്തം ഓതന്റിക്കേഷൻ കൊണ്ടുവരുന്ന രീതിയാണ് — ഒരു ഓതന്റിക്കേഷൻ ലൈബ്രറിയോ ഹോസ്റ്റഡ് ദാതാവോ നിങ്ങൾ തിരഞ്ഞെടുക്കുന്നു, അതിന്റെ കീകൾ പ്രോജക്റ്റ് രഹസ്യങ്ങളായി സൂക്ഷിക്കുന്നു, കോഡ് ഏജന്റ് എഴുതുന്നു. ഇതിനുള്ള ആരംഭ പ്രോംപ്റ്റ് ഓതന്റിക്കേഷൻ ചേർക്കൽ റെസിപ്പിയിൽ ഉണ്ട്. Mythex-ൽ തന്നെ OAuth-ഉം നിങ്ങൾ കാണും: Google ഉപയോഗിച്ച് സൈൻ അപ്പ് ചെയ്യാം, റിപ്പോ സിങ്കിനായി GitHub ബന്ധിപ്പിക്കുന്നത് GitHub OAuth ഉപയോഗിക്കുന്നു, MCP വഴി Mythex-ലേക്ക് കണക്ട് ചെയ്യുന്ന AI ക്ലയന്റുകൾ ഒരു OAuth സമ്മത പേജിലൂടെ പോകുന്നു. കൂടുതലറിയാൻ ഓതന്റിക്കേഷൻ എന്താണ്, ടു-ഫാക്ടർ ഓതന്റിക്കേഷൻ എന്താണ് എന്നിവ നോക്കുക.

ചോദ്യങ്ങൾ