Ի՞նչ է OAuth-ը։ «Sign in with Google»-ը և պատվիրակված հասանելիությունը

OAuth-ը բաց ստանդարտ է, որը թույլ է տալիս օգտատիրոջը սահմանափակ մուտք տալ մի հավելվածի իր հաշվին մեկ այլ ծառայության վրա՝ առանց իր գաղտնաբառը փոխանցելու։ Երբ սեղմում եք «Connect Google Calendar» և տեսնում եք էկրան, որը հարցնում է՝ «Թույլ տա՞լ այս հավելվածին տեսնել ձեր իրադարձությունները», դա OAuth է։ Հավելվածը ստանում է token, որը ճշգրիտ համապատասխանում է այն բանին, ինչ հաստատել եք, և որը կարող եք ցանկացած պահի չեղարկել։ Նույն մեխանիզմը, լրացուցիչ OpenID Connect շերտով, ապահովում է «Sign in with Google» և նմանատիպ կոճակները։

Ինչու է OAuth-ը կարևոր AI-ով կառուցելիս

OAuth-ը երկու տարածված իրավիճակում է հայտնվում, երբ հավելված եք կառուցում․

1. Սոցիալական մուտք։ Ուզում եք, որ ձեր օգտատերերը մուտք գործեն «Sign in with Google» (կամ Apple, Microsoft, GitHub) կոճակով՝ առանց մեկ ուրիշ գաղտնաբառ ստեղծելու։ Տես ինչպես ավելացնել մուտք ձեր հավելվածին։
2. Միանալ օգտատերերի հաշիվներին այլ ծառայություններում։ Ձեր հավելվածին պետք է կարդալ օգտատիրոջ օրացույցը, գրառումներ անել նրա սոցիալական հաշվում, վերցնել ֆայլեր նրա cloud drive-ից կամ համաժամեցնել հաշվապահական տվյալները։

Ամեն դեպքում ձեր AI կառուցողը կարող է գրել կոդը, բայց որոշ քայլեր միայն դուք կարող եք անել․ ստեղծել մշակողական հավելված մատակարարի հետ, ստանալ client ID և client secret, գրանցել callback URL-ներ և, որոշ թույլտվությունների համար, անցնել մատակարարի վերանայումը։ OAuth-ի իմացությունը այդ քայլերը և դրանց տված սխալները շատ պակաս առեղծվածային է դարձնում։ Մուտքի ավելի լայն պատկերի համար տես ինչ է authentication-ը։

Ամենօրյա անալոգիա

Մտածեք հյուրանոցի բանալու քարտի մասին։ Ժամանակ ընդունվելիս ռեսեպշնը ստուգում է, թե ով եք, ապա տալիս է քարտ, որ բացում է ձեր սենյակը և մարզասրահը՝ ոչ այլ սենյակներ, ոչ աշխատակիցների տարածքներ, և դադարում է աշխատել ելքի ժամանակ։ Քարտը ձեր անձնագիրը չի պարունակում։ Եթե այն կորչի, ռեսեպշնը չեղարկում է այն և տալիս նորը։

• Ռեսեպշնը թույլտվության սերվերն է (Google-ի մուտքի էջը)։
• Ձեր ինքնության ստուգումը Google-ում ձեր մուտքն է։
• Բանալու քարտը access token-ն է։
• «Սենյակը և մարզասրահը միայն» ձեր հաստատած scope-երն են։
• Ելքը token-ի ժամկետի ավարտն է, կամ դուք հասանելիությունը չեղարկում եք։

Հավելվածը, որ օգտագործում եք, երբեք չի տեսնում ձեր Google գաղտնաբառը, միայն բանալու քարտը։

Ինչպես է աշխատում OAuth-ը, քայլ առ քայլ

Վեբ հավելվածների համար ամենատարածված հոսքը authorization code flow-ն է։ Ահա, թե ինչ է լինում, երբ օգտատերը միացնում է իր Google Calendar-ը ժամանակացույցի հավելվածին․

1. Սեղմում։ Օգտատերը սեղմում է «Connect Google Calendar»։
2. Վերահղում մատակարարին։ Հավելվածը բրաուզերն ուղարկում է Google, իր client ID-ով, պահանջվող scope-երով (կարդալ օրացույցի իրադարձությունները) և 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-ն access token-ով և ստանում օգտատիրոջ իրադարձությունները։

Քայլ 4-ի callback-ը նման է սրան՝

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

Եվ քայլ 5-ի token պատասխանը JSON է այսպես՝

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

Կարևոր նախագծային կետը․ token-ի փոխանակումը տեղի է ունենում սերվեր-սերվեր, ուստի client secret-ը և token-ները երբեք պետք չէ անցնեն բրաուզերով։

OAuth vs OpenID Connect vs ձեր սեփական մուտքը

Շատ հավելվածներ համատեղում են դրանք․ էլ. փոստ-գաղտնաբառ մուտք, գումարած «Sign in with Google» OIDC-ով, գումարած առանձին OAuth միացումներ այլ ծառայությունների հետ։

Հիմնական տերմիններ

Սովորական թյուրըմբռնումներ

• «OAuth-ը մուտքի համակարգ է»։ Պարզ OAuth-ը տալիս է հասանելիություն, իսկ նույնականացումը OpenID Connect-ն է անում։ Մերկ access token-ը որպես ապացույց, թե ով է մարդը, իրական անվտանգության սխալների պատճառ է եղել։
• «Հավելվածը ստանում է իմ գաղտնաբառը»։ Երբեք։ Դա է հենց կետը։
• «Ավելի շատ scope-եր խնդրելը անվնաս է»։ Օգտատերերը ավելի զգույշ են լայն հարցումների նկատմամբ, և մատակարարները, ինչպես Google-ը, կարող են պահանջել հավելվածի վերանայում զգայուն կամ սահմանափակ scope-երի համար։ Խնդրեք միայն այն, ինչ պետք է։
• «Client secret-ը կարող է լինել frontend-ում»։ Ամեն ինչ, որ բրաուզերի կոդում է, հանրային է։ Պահեք այն սերվերային գաղտնիքներում։
• «Աշխատում է թեստավորման մեջ, ուրեմն կաշխատի արտադրության մեջ»։ Մատակարարները հաճախ սահմանափակում են չհաստատված հավելվածները, օրինակ՝ ցուցակված թեստային օգտատերերով, և ձեր կենդանի դոմենի redirect URI-ը պետք է առանձին գրանցվի։
• «Token-ները երբեք չեն ավարտվում»։ Access token-ները արագ են ժամկետանց լինում, և օգտատերերը կարող են թույլտվությունը չեղարկել։ Ձեր հավելվածը պետք է կարողանա երկուսն էլ դիմանալ։

Ինչ հարցնել ձեր AI կառուցողից

• «Ավելացրու «Sign in with Google»՝ OpenID Connect-ով և լավ պահպանվող մուտքի գրադարանով․ OAuth հոսքը ձեռքով մի գրիր։»
• «Օգտագործիր authorization code flow PKCE-ով և ստուգիր state պարամետրը։»
• «Կարդա client ID-ն և client secret-ը սերվերում՝ միջավայրի փոփոխականներից։»
• «Խնդրիր միայն մեզ անհրաժեշտ scope-երը՝ միայն կարդալու օրացույցի հասանելիություն։»
• «Ասա ինձ բոլոր redirect URL-ները, որ պետք է գրանցեմ մատակարարի կոնսոլում՝ նախադիտման, հրապարակված URL-ի և անհատական դոմենի համար։»
• «Պահիր refresh token-ները կոդավորված տվյալների բազայում և վարվիր ժամկետանց կամ չեղարկված token-ների հետ՝ օգտատիրոջից խնդրելով նորից միանալ։»
• «Թույլ տուր օգտատերերին անջատել ինտեգրումը իրենց կարգավորումների էջից։»

OAuth-ը և Mythex-ը

Mythex-ը չունի ներկառուցված վերջնական օգտատիրոջ մուտք կառուցած հավելվածների համար․ իր փաստաթղթերը նկարագրում են «բեր քո սեփականը» (bring-your-own) մոտեցում․ ընտրում եք նույնականացման գրադարան կամ հոսթված մատակարար, պահում եք դրա բանալիները որպես նախագծի գաղտնիքներ, իսկ agent-ը գրում է կոդը։ Authentication ավելացնելու բաղադրատոմսը ունի սկզբնական հուշում դրա համար։ OAuth-ի հետ նաև հանդիպում եք Mythex-ում հենց ինքնին․ կարող եք մուտք գործել Google-ով, GitHub-ը միացնելը repo համաժամեցման համար օգտագործում է GitHub OAuth, իսկ AI օգնականները, որոնք միանում են Mythex-ին MCP-ով, անցնում են OAuth համաձայնության էջով։ Ավելին՝ տես ինչ է authentication-ը և ինչ է երկուական նույնականացումը։

Հարցեր