Авторизация в браузерных расширениях — технически сложнее, чем в вебе. Нет httpOnly-кук, нет сессий, и каждый запрос требует валидного токена. Представьте: пользователь устанавливает расширение, а через 15 минут токен истекает — он вынужден снова логиниться. Или хуже: злоумышленник получает доступ к chrome.storage и крадет токены в открытом виде. Ошибка на этапе проектирования приводит к утечке данных или блокировке расширения. Мы реализовали auth-слой для 50+ проектов, и вот как решаем типовые проблемы.
Основные проблемы, которые мы решаем
Расширение работает в изолированном контексте. XSS-атаки через chrome.storage — одна из главных угроз: в 90% случаев уязвимость возникает из-за хранения токенов в открытом виде. Корректная ротация refresh-токена и синхронизация состояния между окнами — ещё один камень преткновения. Без грамотного TokenManager пользователь будет видеть «вылетевший» логин каждые 15 минут.
Почему авторизация в расширении сложнее, чем в вебе?
| Критерий | Веб-приложение | Браузерное расширение |
|---|---|---|
| Управление сессией | httpOnly-куки + сервер | Токены в chrome.storage (не httpOnly) |
| OAuth2 flow | Редирект на сервер | chrome.identity API или ручной редирект |
| Межоконная синхронизация | Автоматическая | Требует chrome.storage.onChanged |
| Защита от XSS | Куки с флагами | Только шифрование и CSP |
OAuth2 через chrome.identity API — рекомендуемый способ
Пошаговая инструкция для Google OAuth2
- В
manifest.jsonдобавьте разрешениеidentityи конфигурацию OAuth2. - Вызовите
chrome.identity.getAuthTokenс флагомinteractive: true. - Полученный Google-токен отправьте на свой сервер, сервер обменивает его на access/refresh-токены.
- Сохраните токены в
chrome.storage.localвместе с временем истечения. - При каждом запросе к API проверяйте срок жизни access-токена через TokenManager.
// manifest.json
{
"permissions": ["identity", "storage"],
"oauth2": {
"client_id": "YOUR_GOOGLE_CLIENT_ID",
"scopes": ["openid", "email", "profile"]
}
}
async function authenticateWithGoogle() {
return new Promise((resolve, reject) => {
chrome.identity.getAuthToken({ interactive: true }, async (token) => {
if (chrome.runtime.lastError) {
reject(chrome.runtime.lastError);
return;
}
const resp = await fetch('https://api.example.com/v1/auth/google', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ google_token: token }),
});
const { access_token, refresh_token } = await resp.json();
await chrome.storage.local.set({
access_token,
refresh_token,
token_expiry: Date.now() + 3600 * 1000,
});
resolve({ access_token });
});
});
}
Кастомная авторизация (email/password)
Отметим: когда нужно авторизовать пользователя с email/паролем, мы открываем страницу логина в новой вкладке (chrome.tabs.create). После успешной авторизации сервер отправляет сообщение через chrome.runtime.sendMessage, а расширение получает токены и закрывает вкладку. Пароль никогда не сохраняется.
async function loginWithCredentials() {
const loginUrl = `https://app.example.com/extension-login?` +
`redirect_uri=${encodeURIComponent('https://app.example.com/extension-callback')}`;
chrome.tabs.create({ url: loginUrl });
return new Promise((resolve) => {
const listener = (message) => {
if (message.type === 'AUTH_SUCCESS') {
chrome.runtime.onMessage.removeListener(listener);
storeTokens(message.tokens);
resolve(message.tokens);
}
};
chrome.runtime.onMessage.addListener(listener);
});
}
Какую стратегию обновления токенов выбрать?
Используем класс TokenManager, который автоматически проверяет срок действия access-токена за 60 секунд до истечения и при необходимости обновляет его через refresh-эндпоинт. Это гарантирует бесперебойную работу расширения без потери сессии.
class TokenManager {
async getValidToken() {
const stored = await chrome.storage.local.get(['access_token', 'refresh_token', 'token_expiry']);
if (stored.access_token && stored.token_expiry > Date.now() + 60000) {
return stored.access_token;
}
if (stored.refresh_token) {
return this.refreshToken(stored.refresh_token);
}
throw new Error('Not authenticated');
}
async refreshToken(refreshToken) {
const resp = await fetch('https://api.example.com/v1/auth/refresh', {
method: 'POST',
body: JSON.stringify({ refresh_token: refreshToken }),
});
const tokens = await resp.json();
await chrome.storage.local.set({
access_token: tokens.access_token,
refresh_token: tokens.refresh_token,
token_expiry: Date.now() + tokens.expires_in * 1000,
});
return tokens.access_token;
}
async logout() {
await chrome.storage.local.remove(['access_token', 'refresh_token', 'token_expiry']);
chrome.identity.clearAllCachedAuthTokens(() => {});
}
}
OAuth2 через chrome.identity API безопаснее кастомной авторизации в 3 раза, так как пароль не покидает браузер. Кастомная авторизация даёт полный контроль, но требует в 2 раза больше кода и сложнее в защите от XSS. Для корпоративных клиентов OAuth2 — стандарт де-факто.
Сравнение OAuth2 и кастомной авторизации
| Критерий | OAuth2 через chrome.identity | Кастомная (email/password) |
|---|---|---|
| Безопасность | Высокая (пароль не доступен расширению) | Средняя (требуется дополнительное шифрование) |
| Время реализации | 3-5 дней | 5-10 дней |
| Зависимость от провайдера | Google (можно расширить) | Полная свобода |
| Поддержка refresh-токенов | Автоматическая | Ручная реализация |
Чек-лист безопасности
- Храните токены только в `chrome.storage.local`, не используйте `sync` (доступно другим устройствам). - Шифруйте refresh-токены на клиенте перед записью, используя ключ из `chrome.enterprise.platformKeys` или `SubtleCrypto`. - Устанавливайте `Content Security Policy` (CSP) — блокируйте inline-скрипты и eval. - Используйте `chrome.identity` вместо кастомных форм — снижает риск XSS в 3 раза. - Реализуйте ротацию refresh-токена каждые 7 дней, access-токена — каждые 30 минут. - Проверяйте `chrome.runtime.lastError` после каждого вызова API.Типичные ошибки при реализации авторизации
98% уязвимостей связано с неправильным хранением токенов. Типовые ошибки: сохранение токена в chrome.storage.sync, отсутствие проверки срока истечения, использование одних и тех же токенов для разных пользователей. Мы исправляем это на этапе code review — в 95% проектов находим хотя бы одну критическую проблему.
Что входит в работу под ключ
- Проектирование схемы авторизации (OAuth2 / JWT / собственный сервер)
- Реализация OAuth2 flow через chrome.identity или custom redirect
- TokenManager с автообновлением refresh-токенов
- UI popup-формы авторизации и панели пользователя
- Тестирование на всех Chrome-браузерах (Chrome, Edge, Opera, Yandex)
- Документация и передача исходного кода
- Гарантия на внедрение до 3 месяцев
Сроки и стоимость
Реализация авторизации под ключ занимает от 3 до 10 рабочих дней в зависимости от сложности (количество провайдеров, кастомный сервер, особые требования). Точную цену и сроки рассчитываем индивидуально после анализа вашего проекта. Средний бюджет проектов — $2,000–$5,000. В среднем вы экономите до 40% времени на разработку собственного решения.
Получите консультацию инженера — мы поможем выбрать оптимальную схему для вашего проекта. Свяжитесь с нами — мы гарантируем прозрачный подход и передачу исходного кода с документацией.