Ano ang OAuth? Ipinaliwanag ang “Sign in with Google” at Delegated Access

Ang OAuth ay bukas na pamantayan na nagpapahintulot sa isang user na bigyan ang isang app ng limitadong access sa account nila sa ibang serbisyo, nang hindi ibinibigay ang password nila. Kapag na-click mo ang “Connect Google Calendar” at may lumabas na screen na nagtatanong ng “Payagan ang app na ito na makita ang mga event mo?”, OAuth iyon. Nakakakuha ang app ng token para eksakto sa inaprubahan mo, na puwede mong bawiin anumang oras. Ang parehong makinarya, kasama ang dagdag na layer na tinatawag na OpenID Connect, ang nagpapagana ng “Sign in with Google” at mga katulad na button.

Bakit mahalaga ang OAuth kapag gumagawa ka gamit ang AI

Lumalabas ang OAuth sa dalawang karaniwang sitwasyon kapag gumagawa ka ng app:

1. Social login. Gusto mong makapag-“Sign in with Google” (o Apple, Microsoft, GitHub) ang mga user mo sa halip na gumawa ng isa pang password. Tingnan ang paano magdagdag ng login sa app mo.
2. Pagkonekta sa mga account ng user sa ibang serbisyo. Kailangan ng app mo na basahin ang kalendaryo ng user, mag-post sa social account nila, kumuha ng file mula sa cloud drive nila, o i-sync ang datos nila sa accounting.

Sa parehong kaso, maisusulat ng AI builder mo ang code, pero may ilang hakbang na ikaw lang ang makakagawa: gumawa ng developer app sa provider, kumuha ng client ID at client secret, magrehistro ng callback URL, at para sa ilang pahintulot, pumasa sa review ng provider. Kapag alam mo kung paano gumagana ang OAuth, mas kaunti na ang misteryo sa mga hakbang na iyon at sa mga error na nalilikha nila. Para sa mas malaking larawan ng login, tingnan ang ano ang authentication.

Halimbawang madaling maintindihan

Isipin ang key card ng hotel. Sa check-in, kinukumpirma ng front desk kung sino ka, saka ka binibigyan ng card na nagbubukas ng kuwarto mo at ng gym — hindi ng ibang kuwarto, hindi ng mga lugar ng staff — at tumitigil sa paggana pagdating ng check-out. Hindi nakalagay sa card ang pasaporte mo. Kung mawala ito, kakanselahin ito ng desk at maglalabas ng bago.

• Ang front desk ang authorization server (ang sign-in page ng Google).
• Ang pagkumpirma ng pagkakakilanlan mo ay ang pag-log in mo sa Google.
• Ang key card ang access token.
• “Kuwarto at gym lang” ang mga scope na inaprubahan mo.
• Ang check-out ang pag-expire ng token, o ang pagbawi mo ng access.

Hindi kailanman nakikita ng app na ginagamit mo ang password mo sa Google, ang key card lang.

Paano gumagana ang OAuth, hakbang-hakbang

Ang pinakakaraniwang daloy para sa web app ay ang authorization code flow. Ito ang nangyayari kapag ikinonekta ng user ang Google Calendar nila sa isang scheduling app:

1. I-click. Ki-click ng user ang “Connect Google Calendar.”
2. I-redirect sa provider. Ipinapadala ng app ang browser sa Google kasama ang client ID nito, ang mga scope na gusto nito (basahin ang mga event sa kalendaryo), at ang redirect URI kung saan dapat ibalik ng Google ang user.
3. Mag-log in at pumayag. Mag-sa-sign in ang user sa Google (kung hindi pa) at makikita ang consent screen na naglilista ng hinihingi ng app. Ki-click nila ang Allow.
4. Balik na may code. Nire-redirect ng Google ang browser sa redirect URI ng app kasama ang panandalian at minsanang authorization code.
5. Palitan sa server. Ipinapadala ng server ng app ang code na iyon, kasama ang client secret nito, direkta sa Google at tumatanggap ng access token (at madalas ay refresh token).
6. Gamitin ang API. Tinatawag ng server ang API ng Google Calendar gamit ang access token at kinukuha ang mga event ng user.

Ganito ang hitsura ng callback sa hakbang 4:

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

At ang token response sa hakbang 5 ay JSON na ganito:

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

Ang mahalagang punto sa disenyo: nangyayari ang palitan ng token sa pagitan ng mga server, kaya hindi kailangang dumaan sa browser ang client secret at mga token.

OAuth vs OpenID Connect vs sarili mong login

Maraming app ang pinagsasama ang mga ito: login gamit ang email at password, dagdag ang “Sign in with Google” sa pamamagitan ng OIDC, at hiwalay na OAuth connection sa ibang serbisyo.

Mga pangunahing termino

Mga karaniwang maling akala

• “Sistema ng login ang OAuth.” Ang simpleng OAuth ay nagbibigay ng access; ang OpenID Connect ang humahawak ng pagkakakilanlan. Ang paggamit ng hubad na access token bilang patunay kung sino ang isang tao ay nagdulot na ng totoong security bug.
• “Nakukuha ng app ang password ko.” Hindi kailanman. Iyon ang punto.
• “Walang panganib ang paghingi ng mas maraming scope.” Mas nag-iingat ang mga user sa malawak na hiling, at maaaring mangailangan ang mga provider gaya ng Google ng app review para sa sensitibo o restricted na scope. Humingi lang ng kailangan mo.
• “Puwedeng ilagay ang client secret sa frontend.” Anumang nasa browser code ay pampubliko. Ilagay ito sa server-side na mga secret.
• “Gumagana sa testing, kaya gagana rin sa production.” Madalas nililimitahan ng mga provider ang mga hindi beripikadong app — halimbawa, sa mga nakalistang test user — at kailangang irehistro nang hiwalay ang redirect URI ng live domain mo.
• “Habambuhay ang mga token.” Mabilis mag-expire ang access token, at puwedeng bawiin ng user ang access. Kailangang hawakan nang maayos ng app mo ang pareho.

Ano ang itanong sa AI builder mo

• “Magdagdag ng ‘Sign in with Google’ gamit ang OpenID Connect at isang maayos na napapanatiling auth library — huwag mong gawin nang mano-mano ang OAuth flow.”
• “Gumamit ng authorization code flow na may PKCE at suriin ang state parameter.”
• “Basahin ang client ID at client secret mula sa environment variables sa server.”
• “Humingi lang ng mga scope na kailangan natin: read-only na access sa kalendaryo.”
• “Sabihin mo sa akin ang bawat redirect URL na kailangan kong irehistro sa console ng provider, para sa preview, sa published URL, at sa custom domain ko.”
• “I-store nang naka-encrypt ang refresh token sa database, at kapag expired o binawi ang token, hingin sa user na muling kumonekta.”
• “Payagan ang mga user na i-disconnect ang integration sa settings page nila.”

OAuth at Mythex

Wala ang Mythex ng built-in na end-user login para sa mga app na ginagawa mo; ang docs nito ay naglalarawan ng bring-your-own na paraan — pipili ka ng auth library o hosted provider, iniimbak ang mga key nito bilang project secrets, at ang agent ang sumusulat ng code. Nasa add authentication recipe ang starter prompt para dito. Makakatagpo ka rin ng OAuth sa mismong Mythex: puwede kang mag-sign up gamit ang Google, ang pagkonekta ng GitHub para sa repo sync ay gumagamit ng GitHub OAuth, at ang mga AI client na kumokonekta sa Mythex sa pamamagitan ng MCP ay dumadaan sa OAuth consent page. Para sa higit pa, tingnan ang ano ang authentication at ano ang two-factor authentication.

Mga tanong