OAuth શું છે? "Google સાથે સાઇન ઇન" અને પ્રતિનિધિત્વ ઍક્સેસ સમજાવ્યું

OAuth એ ખુલ્લું માનક છે, જે યુઝરને પોતાનો પાસવર્ડ આપ્યા વિના એક એપને બીજી સેવામાં તેના એકાઉન્ટની મર્યાદિત ઍક્સેસ આપવા દે છે. જ્યારે તમે "Google Calendar જોડો" ક્લિક કરો અને "શું આ એપને તમારા ઇવેન્ટ્સ જોવાની મંજૂરી આપવી?" પૂછતી સ્ક્રીન જુઓ, તે OAuth છે. એપને તમે મંજૂર કરેલી ચોક્કસ વસ્તુ માટેનું ટોકન મળે છે, જે તમે ગમે ત્યારે રદ કરી શકો છો. એ જ મિકેનિઝમ, વધારાના OpenID Connect સ્તર સાથે, "Google સાથે સાઇન ઇન" અને તેવાં બટનોને શક્તિ આપે છે.

AI સાથે બિલ્ડ કરતી વખતે OAuth શા માટે મહત્વનું છે

એપ બનાવતી વખતે OAuth બે સામાન્ય પરિસ્થિતિઓમાં દેખાય છે:

1. સોશિયલ લૉગિન. તમે ઇચ્છો છો કે તમારા યુઝર્સ નવો પાસવર્ડ બનાવવાને બદલે "Google સાથે સાઇન ઇન" (અથવા Apple, Microsoft, GitHub) કરે. જુઓ તમારી એપમાં લૉગિન કેવી રીતે ઉમેરવું.
2. બીજી સેવાઓમાં યુઝર્સના એકાઉન્ટ સાથે જોડાણ. તમારી એપને યુઝરનું calendar વાંચવાની, તેના સોશિયલ એકાઉન્ટ પર પોસ્ટ કરવાની, તેના cloud drive માંથી ફાઇલો ખેંચવાની અથવા તેનો accounting ડેટા સિંક કરવાની જરૂર પડી શકે છે.

બંને કિસ્સાઓમાં તમારો AI બિલ્ડર કોડ લખી શકે છે, પણ કેટલાંક પગલાં માત્ર તમે જ કરી શકો: provider સાથે developer એપ બનાવવી, client ID અને client secret મેળવવી, callback URLs નોંધાવવા અને કેટલીક પરવાનગીઓ માટે provider ની સમીક્ષામાંથી પસાર થવું. OAuth કેવી રીતે કામ કરે છે તે જાણવાથી એ પગલાં — અને તેમાંથી આવતી ભૂલો — ઓછી રહસ્યમય લાગે છે. લૉગિનનું મોટું ચિત્ર માટે જુઓ ઓથેન્ટિકેશન શું છે.

રોજિંદું ઉદાહરણ

હોટલના કી-કાર્ડનો વિચાર કરો. ચેક-ઇન વખતે ફ્રન્ટ ડેસ્ક ચકાસે છે કે તમે કોણ છો, પછી તમને એક કાર્ડ આપે છે જે તમારો રૂમ અને જિમ ખોલે છે — બીજા રૂમ કે સ્ટાફ વિસ્તારો નહીં — અને ચેક-આઉટ પર કામ કરવાનું બંધ કરે છે. કાર્ડમાં તમારો પાસપોર્ટ નથી. ખોવાય તો ડેસ્ક તેને રદ કરીને નવું આપે છે.

• ફ્રન્ટ ડેસ્ક એ authorization server છે (Google નું સાઇન-ઇન પેજ).
• તમારી ઓળખ તપાસ એ Google માં તમારું લૉગિન છે.
• કી-કાર્ડ એ access token છે.
• "માત્ર રૂમ અને જિમ" એ તમે મંજૂર કરેલા scopes છે.
• ચેક-આઉટ એ ટોકનની મુદત પૂરી થવી, અથવા તમે ઍક્સેસ રદ કરવી.

તમે જે એપ વાપરી રહ્યા છો તે ક્યારેય તમારો Google પાસવર્ડ જોતી નથી, માત્ર કી-કાર્ડ.

OAuth પગલાંવાર કેવી રીતે કામ કરે છે

વેબ એપ્સ માટેનો સૌથી સામાન્ય ફ્લો authorization code flow છે. જ્યારે યુઝર શેડ્યૂલિંગ એપ સાથે પોતાનું Google Calendar જોડે ત્યારે આ થાય છે:

1. ક્લિક. યુઝર "Google Calendar જોડો" ક્લિક કરે છે.
2. Provider તરફ રીડાયરેક્ટ. એપ બ્રાઉઝરને તેના client ID, જોઈતા scopes (calendar events વાંચવા) અને redirect URI સાથે Google પર મોકલે છે, જ્યાં Google યુઝરને પાછો મોકલે.
3. લૉગિન અને સંમતિ. યુઝર Google માં સાઇન ઇન કરે છે (જો પહેલેથી ન હોય) અને પરવાનગીઓની યાદી બતાવતી સંમતિ સ્ક્રીન જુએ છે. તે Allow ક્લિક કરે છે.
4. કોડ સાથે પાછા. Google બ્રાઉઝરને એપના redirect URI પર ટૂંકા-ગાળાના, એકવારના authorization code સાથે પાછું મોકલે છે.
5. સર્વર પર વિનિમય. એપનું સર્વર તે કોડ, તેની client secret સાથે સીધું Google ને મોકલે છે અને access token (અને ઘણી વાર refresh token) મેળવે છે.
6. API વાપરો. સર્વર access token સાથે Google Calendar API કૉલ કરે છે અને યુઝરની ઇવેન્ટ્સ મેળવે છે.

પગલું 4 નો callback આના જેવો દેખાય છે:

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 વિરુદ્ધ OpenID Connect વિરુદ્ધ તમારું પોતાનું લૉગિન

ઘણી એપ્સ તેમને સંયોજિત કરે છે: ઈમેઇલ-અને-પાસવર્ડ લૉગિન, વત્તા OIDC દ્વારા "Google સાથે સાઇન ઇન", વત્તા બીજી સેવાઓ સાથે અલગ OAuth જોડાણો.

મુખ્ય શબ્દો

સામાન્ય ગેરસમજો

• "OAuth એ લૉગિન સિસ્ટમ છે." સાદું OAuth ઍક્સેસ આપે છે; OpenID Connect ઓળખ સંભાળે છે. કોઈ વ્યક્તિ કોણ છે તેનો પુરાવો તરીકે માત્ર access token વાપરવાથી વાસ્તવિક સુરક્ષા bugs થયા છે.
• "એપને મારો પાસવર્ડ મળે છે." ક્યારેય નહીં. એ જ તો મુદ્દો છે.
• "વધુ scopes માંગવા હાનિકારક નથી." યુઝર્સ વિશાળ વિનંતીઓથી સાવચેત રહે છે, અને Google જેવા provider સંવેદનશીલ અથવા પ્રતિબંધિત scopes માટે એપ સમીક્ષાની માંગ કરી શકે છે. ફક્ત જેની જરૂર છે તે જ માંગો.
• "Client secret frontend માં મૂકી શકાય." બ્રાઉઝર કોડમાં જે કંઈ છે તે જાહેર છે. તેને સર્વર-બાજુ secrets માં રાખો.
• "ટેસ્ટિંગમાં કામ કરે છે, એટલે પ્રોડક્શનમાં પણ કરશે." Provider ઘણી વાર ચકાસાયેલ ન હોય એવી એપ્સને મર્યાદિત કરે છે — ઉદાહરણ તરીકે યાદીબદ્ધ test users સુધી — અને તમારા લાઇવ domain માટેનો redirect URI અલગથી નોંધાવવો પડે છે.
• "ટોકન્સ હંમેશ માટે ચાલે છે." Access tokens ઝડપથી સમાપ્ત થાય છે, અને યુઝર ઍક્સેસ રદ કરી શકે છે. તમારી એપે બંનેને સરળતાથી સંભાળવા પડે.

તમારા AI બિલ્ડરને શું પૂછવું

• "OpenID Connect સાથે સારી રીતે જાળવાતી auth library વડે 'Google સાથે સાઇન ઇન' ઉમેરો — OAuth ફ્લો જાતે ન ઘડો."
• "PKCE સાથે authorization code flow વાપરો અને state parameter તપાસો."
• "Client ID અને client secret ને સર્વર પર environment variables માંથી વાંચો."
• "જરૂરી scopes જ માંગો: માત્ર વાંચવા માટે calendar ઍક્સેસ."
• "Provider ના console માં મારે નોંધાવવાના દરેક redirect URL કહો, preview, પ્રકાશિત URL અને મારા કસ્ટમ domain માટે."
• "Refresh tokens ને database માં encrypted રીતે સાચવો, અને expired અથવા રદ થયેલા ટોકન્સને યુઝરને ફરી કનેક્ટ કરવા કહીને સંભાળો."
• "યુઝરને તેમના settings પેજ પરથી integration ડિસ્કનેક્ટ કરવા દો."

OAuth અને Mythex

Mythex પાસે તમે બનાવેલી એપ્સ માટે બિલ્ટ-ઇન એન્ડ-યુઝર લૉગિન નથી; તેના docs "તમારું પોતાનું લાવો" અભિગમ વર્ણવે છે — તમે auth library અથવા હોસ્ટેડ provider પસંદ કરો, તેની keys પ્રોજેક્ટ secrets તરીકે સાચવો, અને agent કોડ લખે છે. તેના માટે authentication ઉમેરવાની recipe માં શરૂઆતનો પ્રોમ્પ્ટ છે. Mythex માં જ તમને OAuth પણ દેખાશે: તમે Google વડે સાઇન અપ કરી શકો છો, repo sync માટે GitHub જોડવું GitHub OAuth વાપરે છે, અને MCP દ્વારા Mythex સાથે જોડાતા AI clients એક consent પેજમાંથી પસાર થાય છે. વધુ માટે જુઓ ઓથેન્ટિકેશન શું છે અને ટુ-ફેક્ટર ઓથેન્ટિકેશન શું છે.

પ્રશ્નો