Што е OAuth? „Најавете се со Google“ и делегиран пристап објаснети
OAuth е отворен стандард што му овозможува на корисникот да даде на една апликација ограничен пристап до неговата сметка на друга услуга, без да ја предаде својата лозинка. Кога кликнуваш „Connect Google Calendar“ и ќе видиш екран што прашува „Дозволи оваа апликација да ги гледа твоите настани?“, тоа е OAuth. Апликацијата добива токен само за она што си го одобрил, а тоа можеш да го повлечеш во секое време. Истиот механизам, со дополнителен слој наречен OpenID Connect, стои зад „Најавете се со Google“ и слични копчиња.
Зошто OAuth е важен кога градиш со вештачка интелигенција
OAuth се јавува во две вообичаени ситуации кога градиш апликација:
- Социјална најава. Сакаш твоите корисници да се „најавуваат со Google“ (или Apple, Microsoft, GitHub) наместо да создаваат уште една лозинка. Види како да додадеш најава во твојата апликација.
- Поврзување со сметките на корисниците на други услуги. Твојата апликација треба да го чита календарот на корисникот, да објавува на неговата социјална сметка, да вчитува датотеки од неговиот облачен диск или да ги синхронизира сметководствените податоци.
Во двата случаи AI алатката може да го напише кодот, но некои чекори можеш да ги направиш само ти: да создадеш програмерска апликација кај давателот, да добиеш client ID и client secret, да ги регистрираш callback URL-адресите и, за некои дозволи, да поминеш преглед од давателот. Ако знаеш како функционира OAuth, овие чекори — и грешките што ги предизвикуваат — стануваат многу помалку мистериозни. За поширока слика за најавувањето, види што е автентикација.
Секојдневна аналогија
Замисли картичка-клуч за хотелска соба. При пријавувањето, рецепцијата потврдува кој си, па ти дава картичка што ја отвора твојата соба и теретаната — не другите соби, не просториите за персоналот — и престанува да работи при одјавување. Картичката не содржи твој пасош. Ако ја изгубиш, рецепцијата ја поништува и издава нова.
- Рецепцијата е авторизацискиот сервер (страницата за најава на Google).
- Проверката на твојот identitet е твоето најавување на Google.
- Картичката-клуч е access token-от.
- „Само соба и теретана“ се scopes што си ги одобрил.
- Одјавувањето е истекувањето на токенот или твоето повлекување на пристапот.
Апликацијата што ја користиш никогаш не ја гледа твојата лозинка за Google, туку само картичката-клуч.
Како функционира OAuth, чекор по чекор
Најчестиот тек за веб-апликации е authorization code flow. Ете што се случува кога корисник го поврзува својот Google календар со апликација за закажување:
- Клик. Корисникот кликнува „Connect Google Calendar“.
- Пренасочување кон давателот. Апликацијата го испраќа прелистувачот до Google со својот client ID, scopes што ги бара (читање настани од календарот) и redirect URI, каде Google треба да го врати корисникот.
- Најава и согласност. Корисникот се најавува на Google (ако веќе не е најавен) и гледа екран за согласност со листа на она што го бара апликацијата. Кликнува Allow.
- Назад со код. Google го пренасочува прелистувачот до redirect URI на апликацијата со краткотраен, еднократен authorization code.
- Размена на серверот. Серверот на апликацијата го испраќа тој код, заедно со својот client secret, директно до Google и добива access token (и често refresh token).
- Користење на API-то. Серверот го повикува API-то на Google Calendar со access token-от и ги добива настаните на корисникот.
Callback-от во чекорот 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 сопствена најава
| На што одговара | Пример | |
|---|---|---|
| OAuth 2.0 | „Што смеа оваа апликација да прави во име на корисникот?“ (авторизација) | Читање на календарот на корисникот |
| OpenID Connect (OIDC) | „Кој е корисникот?“ (автентикација), изграден врз OAuth | „Најавете се со Google“ што враќа верифицирана е-пошта |
| Сопствена најава | „Дали е ова точната лозинка за оваа сметка?“ | Е-пошта и лозинка зачувани (хеширани) во твојата база |
Многу апликации ги комбинираат: најава со е-пошта и лозинка, плус „Најавете се со Google“ преку OIDC, плус посебни OAuth поврзувања со други услуги.
Клучни термини
| Термин | Значење |
|---|---|
| Давател / авторизациски сервер | Услугата во која корисникот се најавува и каде дава пристап — Google, Microsoft, GitHub. |
| Client | Твојата апликација, регистрирана кај давателот. |
| Client ID | Јавниот идентификатор на твојата апликација кај давателот. |
| Client secret | Приватната лозинка на твојата апликација кај давателот. Само на сервер. |
| Scope | Конкретна дозвола, како „читај календар“ или „види е-поштенска адреса“. |
| Екран за согласност | Страницата каде корисникот ги гледа и одобрува побараните scopes. |
| Redirect URI / callback URL | Каде давателот го враќа корисникот. Мора однапред да биде регистриран и точно да се совпаѓа. |
| Access token | Краткотрајен акредитив за повикување на API-то. |
| Refresh token | Подолготраен акредитив за добивање нови access токени. Чувај го како лозинка. |
| ID token | Во OIDC, потпишан токен што опишува кој е корисникот. |
| PKCE | Дополнителна проверка („proof key“) што спречува пресретнати кодови да се користат. Препорачана за сите клиенти. |
| state | Случајна вредност што го штити текот од фалсификувани барања. |
Чести погрешни претстави
- „OAuth е систем за најава.“ Обичниот OAuth дава пристап; OpenID Connect ја води идентитетот. Користењето на голем access token како доказ за тоа кој е некој предизвика вистински безбедносни грешки.
- „Апликацијата ја добива мојата лозинка.“ Никогаш. Тоа е поентата.
- „Барањето на повеќе scopes е безопасно.“ Корисниците се поопрезни со широки барања, а даватели како Google може да бараат преглед на апликацијата за чувствителни или ограничени scopes. Барај само она што ти треба.
- „Client secret-от може да оди во фронтендот.“ Сè во кодот на прелистувачот е јавно. Чувај го во тајни на серверот.
- „Работи при тестирање, значи ќе работи и во продукција.“ Даватели често ги ограничуваат непроверените апликации — на пример, на наведени тест-корисници — а redirect URI за твојот live домен мора да се регистрира посебно.
- „Токените траат вечно.“ Access токените брзо истекуваат, а корисниците можат да го повлечат пристапот. Твојата апликација мора убаво да ракува и со двете.
Што да побараш од твојата AI алатка
- „Додај „Најавете се со Google“ преку OpenID Connect со добро одржувана библиотека за автентикација — не пишувај сам OAuth тек.“
- „Користи authorization code flow со PKCE и провери го параметарот
state.“ - „Чувај го client ID и client secret од променливи на околината на серверот.“
- „Бара само scopes што ни требаат: читање на календарот само за читање.“
- „Кажи ми секоја redirect URL што треба да ја регистрирам во конзолата на давателот, за прегледот, за објавената URL-адреса и за мојот прилагоден домен.“
- „Чувај refresh токените шифрирани во базата и кога токените ќе истечат или ќе се повлечат, замоли го корисникот да се поврзе повторно.“
- „Дозволи корисниците да ја прекинат интеграцијата од нивната страница со поставки.“
OAuth и Mythex
Mythex нема вградена најава за крајните корисници на апликациите што ги градиш; документацијата опишува пристап со сопствен провајдер — избираш библиотека за автентикација или хостиран давател, ги чуваш нејзините клучеви како тајни на проектот, а агентот го пишува кодот. Рецептот за додавање автентикација има почетно барање за ова. OAuth ќе го сретнеш и во самиот Mythex: можеш да се најавиш со Google, поврзувањето со GitHub за синхронизација на репозиториумот користи GitHub OAuth, а AI клиентите што се поврзуваат со Mythex преку MCP минуваат низ страница за согласност OAuth. За повеќе, види што е автентикација и што е двофакторска автентикација.
Прашања
Што е OAuth едноставно речено?
OAuth е стандарден начин корисникот да дозволи една апликација да пристапи до неговата сметка на друга услуга — како кога апликација за закажување го чита неговиот Google календар — без да ѝ ја даде својата лозинка. Корисникот одобрува конкретни дозволи, а апликацијата добива токен што може да го користи само за нив.
Дали OAuth е исто што и „Најавете се со Google“?
„Најавете се со Google“ е изграден врз OAuth 2.0 плус OpenID Connect, слој над OAuth што додава стандарден начин да се каже на апликацијата кој е корисникот. OAuth сам по себе е за давање пристап; OpenID Connect е она што го претвора во најава.
Што е OAuth access token?
Access token е акредитив што апликацијата го испраќа до API на една услуга за да докаже дека добила пристап. Обично е краткотраен и ограничен на дозволите (scopes) што корисникот ги одобрил. Refresh token, ако се издаде, ѝ овозможува на апликацијата да добие нови access токени без повторно да го прашува корисникот.
Што значи redirect_uri_mismatch?
Значи дека callback URL-адресата што твојата апликација ја испратила при најавувањето точно не се совпаѓа со една регистрирана во развојната конзола на давателот. Додај ја точната URL-адреса — со https, доменот, патеката и секоја завршна коса црта — за секоја адреса на која работи твојата апликација.
Дали OAuth е безбеден?
OAuth 2.0 е широко користен и безбеден кога е правилно имплементиран: со authorization code flow со PKCE, точни redirect URL-адреси, параметарот state и чување на client secret и токените на серверот. Повеќето проблеми доаѓаат од кратенки при имплементацијата, затоа се препорачува користење добро одржувана библиотека.