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