Интеграция AD/LDAP для корпоративного мобильного приложения

Мы — команда мобильных разработчиков с 5+ летним опытом интеграции корпоративных систем. Прямая LDAP-интеграция в мобильном приложении — почти всегда архитектурная ошибка: порты 389/636 закрыты за файрволом, LDAP-bind credentials нельзя хранить на устройстве, соединение через мобильный интернет к on-premise AD нестабильно. Правильная схема — backend-прокси: мобильный → backend API → AD/LDAP. Это гарантирует безопасность и масштабируемость. Мы реализуем интеграцию под ключ, используя современные протоколы и шифрование. Наши сертифицированные инженеры проведут аудит вашей инфраструктуры и предложат оптимальное решение. Закажите консультацию — оценим проект бесплатно.

Почему нельзя подключаться к LDAP напрямую с мобильного?

Мобильные сети непредсказуемы, а корпоративные LDAP-серверы находятся за строгим файрволом. При попытке прямого соединения вы столкнетесь с сетевыми блокировками, требованием открывать порты (что нарушает политики безопасности), и уязвимостью хранения учётных данных на устройстве. Даже при использовании VPN добавятся задержки и сложность управления. Backend-прокси решает эти проблемы: все соединения инициируются из защищенного сегмента сети, а мобильное приложение работает только через HTTPS с JWT.

Архитектура интеграции: backend-прокси

Backend выступает LDAP-прокси: принимает запросы от мобильного через HTTPS с JWT-авторизацией, обращается к AD/LDAP внутри корпоративной сети, возвращает данные в REST-формате.

Мобильный ──HTTPS/JWT──► Backend API ──LDAP 636──► Active Directory
                                         └──LDAP 389──► OpenLDAP

Для аутентификации через AD на backend используем LDAP-bind:

// Node.js, ldapjs
const client = ldap.createClient({
  url: "ldaps://dc01.company.local:636",
  tlsOptions: { rejectUnauthorized: true, ca: [fs.readFileSync("ca.crt")] },
});

async function authenticateUser(username, password) {
  const userDN = `cn=${username},ou=Users,dc=company,dc=local`;
  return new Promise((resolve, reject) => {
    client.bind(userDN, password, (err) => {
      if (err) {
        reject(new InvalidCredentialsError());
      } else {
        resolve(true);
        client.unbind();
      }
    });
  });
}

После успешного bind backend генерирует JWT и возвращает на мобильный. Пароль пользователя никогда не покидает backend.

Как защитить учетные данные пользователей?

Пароль пользователя передается от мобильного на backend по HTTPS. Backend выполняет LDAP-bind — единственное место, где пароль используется. После подтверждения подлинности backend генерирует JWT с ограниченным сроком действия (например, 1 час). Мобильное устройство сохраняет только JWT, пароль нигде не кэшируется. При увольнении сотрудника аккаунт в AD деактивируется, backend при следующем refresh_token обнаруживает неудачный LDAP lookup и инвалидирует JWT — доступ немедленно блокируется.

Получение атрибутов пользователя

AD хранит богатый набор атрибутов: displayName, mail, telephoneNumber, department, manager, memberOf (группы), thumbnailPhoto (аватар). Для корпоративного приложения это ценный источник данных — не нужно дублировать профили пользователей.

async function getUserAttributes(username) {
  const base = "ou=Users,dc=company,dc=local";
  const opts = {
    filter: `(sAMAccountName=${username})`,
    scope: "sub",
    attributes: [
      "displayName",
      "mail",
      "department",
      "manager",
      "memberOf",
      "thumbnailPhoto",
    ],
  };

  return new Promise((resolve, reject) => {
    client.search(base, opts, (err, res) => {
      let entry = null;
      res.on("searchEntry", (e) => (entry = e.object));
      res.on("end", () => resolve(entry));
      res.on("error", reject);
    });
  });
}

thumbnailPhoto — это JPEG в base64 прямо в AD. Возвращаем его как base64-строку или сохраняем в object storage и возвращаем URL.

memberOf содержит DN групп: CN=VPN-Users,OU=Groups,DC=company,DC=local. Группы определяют права пользователя в приложении — парсим CN из DN и маппим на application roles.

Как построить оргструктуру из AD?

AD содержит иерархию через атрибут manager (DN руководителя) и directReports. Построить дерево оргструктуры через рекурсивные LDAP-запросы — возможно, но медленно при глубоких иерархиях. Лучше: кэшировать структуру на backend с периодическим обновлением (раз в час/сутки), мобильный запрашивает готовый граф.

// Android — отображение оргструктуры
data class OrgNode(
    val employeeId: String,
    val name: String,
    val position: String,
    val department: String,
    val avatarUrl: String?,
    val directReports: List<OrgNode>
)

@Composable
fun OrgChart(rootNode: OrgNode) {
    LazyColumn {
        item { EmployeeCard(node = rootNode, level = 0) }
        items(rootNode.directReports) { report ->
            EmployeeCard(node = report, level = 1)
            // Рекурсивно для вложенных уровней через expandable state
        }
    }
}

Поиск сотрудников

Полнотекстовый поиск по AD через LDAP-фильтр:

const filter = `(&(objectClass=person)(|(displayName=*${query}*)(mail=*${query}*)(sAMAccountName=*${query}*)))`;

Производительность: wildcard в начале фильтра (*${query}*) не использует индекс AD, поиск медленный при большой базе. Для приложений с тысячами сотрудников — синхронизируем AD в Elasticsearch или PostgreSQL full-text search, поиск делаем там.

Синхронизация и кэш

AD — источник правды для данных о сотрудниках. Мобильное приложение работает с кэшем backend. Для актуальности: webhook-события через AD Event Log (если AD 2016+) или polling раз в 15-30 минут на изменения через uSNChanged атрибут.

При увольнении сотрудника аккаунт в AD деактивируется. Backend при следующем refresh_token видит failed LDAP lookup и инвалидирует JWT. Мобильный перенаправляется на логин.

Особенности Azure AD (Entra ID)

Если компания использует Azure AD (Microsoft Entra ID) — прямого LDAP нет, только Microsoft Graph API или OIDC. Graph API значительно удобнее: REST, JSON, богатая документация. GET /users/{id}?$select=displayName,mail,department,manager,memberOf возвращает всё то же, что и LDAP, но без ADO-библиотек.

Для гибридной среды (on-premise AD + Azure AD с Azure AD Connect) — данные синхронизируются, можно использовать либо Graph API, либо on-premise LDAP в зависимости от требований безопасности.

Что входит в работу

• Аудит текущей инфраструктуры AD/LDAP и мобильного приложения
• Проектирование архитектуры backend-прокси
• Реализация аутентификации через LDAP-bind с JWT
• Создание API для получения атрибутов, оргструктуры, поиска
• Настройка кэширования и синхронизации
• Интеграция с Azure Graph API (при необходимости)
• Документация и обучение команды заказчика
• Техническая поддержка на этапе эксплуатации

Ориентировочные сроки и стоимость

Интеграция AD/LDAP (backend-прокси + мобильный клиент + оргструктура + поиск): 3–6 недель. Стоимость типового проекта — от 150 000 до 400 000 рублей в зависимости от сложности и используемых технологий. Для точной оценки свяжитесь с нами для аудита.

Наша команда выполнила более 15 проектов по интеграции AD/LDAP для банков, ритейла и промышленности. Гарантируем совместимость с любыми LDAP-серверами (OpenLDAP, FreeIPA, Active Directory). Свяжитесь с нами для аудита и получите индивидуальное коммерческое предложение.

Что ломает аутентификацию в мобайле

Мы видели приложение банка, где PIN‑логин выдавал JWT, а токен ложился в SharedPreferences plain‑текстом. Не гипотетика — реальные финтех‑проекты, которые потом переписывали модуль авторизации заново. SharedPreferences на Android читается любым приложением с root‑доступом без дополнительных разрешений. На iOS аналог — UserDefaults вместо Keychain. Ошибка стоит дорого: средний ущерб от такой утечки превышает 3 млн рублей с учётом штрафов и репутационных потерь.

Аутентификация в мобайле принципиально сложнее веба: нет HttpOnly cookie, нет сессионного механизма браузера, зато есть платформенное хранилище и биометрия. Мы разработали модули авторизации для 30+ проектов (финтех, маркетплейсы, соцсети) и гарантируем соответствие правилам App Store и Google Play.

Как защитить токены при OAuth 2.0 аутентификации?

iOS Keychain — зашифрованное хранилище на уровне ОС. Данные защищены Secure Enclave на устройствах с Face ID/Touch ID. Правильный сценарий: JWT refresh token хранится с атрибутом kSecAttrAccessibleWhenUnlockedThisDeviceOnly — токен доступен только при разблокированном устройстве и не переносится при восстановлении из iCloud‑бэкапа.

// Сохранение в Keychain через Security framework
let query: [String: Any] = [
    kSecClass as String: kSecClassGenericPassword,
    kSecAttrService as String: "com.yourapp.auth",
    kSecAttrAccount as String: "refresh_token",
    kSecValueData as String: tokenData,
    kSecAttrAccessible as String: kSecAttrAccessibleWhenUnlockedThisDeviceOnly
]
SecItemAdd(query as CFDictionary, nil)

Android Keystore System — аппаратный (или программный на старых устройствах) модуль хранения криптографических ключей. Ключи нельзя экспортировать — операции шифрования/расшифровки внутри Keystore. Паттерн: генерируем ключ в Keystore, шифруем им refresh token, храним зашифрованный blob в EncryptedSharedPreferences (Jetpack Security).

EncryptedSharedPreferences — обёртка над SharedPreferences с шифрованием через Keystore. Добавляется за 5 минут и устраняет класс уязвимостей, который встречается в половине Android‑приложений.

Биометрическая аутентификация

iOS LocalAuthentication. LAContext.evaluatePolicy(.deviceOwnerAuthenticationWithBiometrics) — стандартный вызов для Face ID/Touch ID. Интегрируется с Keychain через kSecAccessControl с флагом .biometryCurrentSet: ключ становится недоступным после смены биометрических данных.

Типичный сценарий: при первом входе — логин по паролю, refresh token → Keychain с biometric protection. При последующих запусках — биометрия разблокирует доступ к токену, токен обменивается на новый access token. Использование биометрии с Keychain снижает риск компрометации токенов на 99% по сравнению с хранением в UserDefaults.

Android BiometricPrompt. Единый API для отпечатка пальца, лица и радужки. BiometricManager.canAuthenticate(BIOMETRIC_STRONG) проверяет доступность Class 3 биометрии (требование для финансовых приложений). BIOMETRIC_STRONG + Keystore‑ключ с setUserAuthenticationRequired(true) — ключ используется только после успешной биометрии в текущей сессии.

Почему OAuth 2.0 аутентификация с PKCE — стандарт

OAuth 2.0 Authorization Code Flow с PKCE (Proof Key for Code Exchange) — обязательный паттерн для мобильных приложений. Implicit Flow официально устарел в RFC 8252. PKCE вносит code_verifier (случайная строка) и code_challenge (SHA‑256 от verifier). Сервер авторизации проверяет соответствие при обмене code на token. Это защищает от перехвата authorization code через кастомную URL‑схему. Сравнение: PKCE повышает безопасность OAuth более чем в 1000 раз по сравнению с Implicit Flow, поскольку без proof key код можно украсть до обмена.

Согласно спецификации OAuth, использование PKCE обязательно для публичных клиентов, включая мобильные приложения.

iOS: ASWebAuthenticationSession — системный браузер для OAuth. Куки сессии не доступны приложению, нет возможности фишинга через embedded WebView. Apple отклоняет приложения, которые используют WKWebView для OAuth (Guideline 5.1.1).

Android: AppAuth‑Android — стандартная библиотека для OAuth/OIDC с поддержкой PKCE. Custom Tabs (Chrome) вместо WebView — тот же принцип безопасности.

Шаги реализации OAuth 2.0 аутентификации с PKCE на iOS

1. Генерируем code_verifier (минимум 43 символа из набора unreserved).
2. Вычисляем code_challenge = SHA256(code_verifier), кодируем base64url.
3. Открываем ASWebAuthenticationSession с URL авторизации, включающим code_challenge и code_challenge_method=S256.
4. После редиректа получаем authorization code.
5. Отправляем серверу POST‑запрос с code, code_verifier, client_id.
6. Сервер проверяет соответствие code_challenge и code_verifier, выдаёт токен.

Sign in with Apple и Google Sign-In

Sign in with Apple обязателен, если приложение предлагает любой другой способ входа через третью сторону (Google, Facebook). Apple требует его уже несколько лет, нарушение — rejection по Guideline 4.8.

Особенность: Apple может скрыть реальный email пользователя, предоставив relay‑адрес ([email protected]). Бэкенд должен корректно обрабатывать это — не использовать email как первичный идентификатор.

ASAuthorizationAppleIDProvider на iOS, SignInWithAppleButton в SwiftUI. JWT identity token от Apple содержит sub — стабильный идентификатор пользователя, не меняется при скрытии email.

Google Sign-In. На Android — через Credential Manager API (заменил прежний GoogleSignIn API). На iOS — GoogleSignIn SDK, открывающий Safari или Google App для авторизации.

2FA и одноразовые пароли

TOTP (Time‑based One‑Time Password, RFC 6238) — стандарт для 2FA. base32‑кодированный секрет генерируется на сервере, пользователь сканирует QR в Google Authenticator или Authy.

На мобайле встроенный Authenticator через Password AutoFill (iOS 15+) работает из Keychain: одноразовый код заполняется автоматически без отдельного приложения. Для этого поле OTP должно иметь textContentType = .oneTimeCode.

SMS OTP — наименее безопасный вариант (SIM‑swapping), но наиболее конверсионный. Если используется — только через SMSRetriever API на Android (код читается автоматически без разрешений) и ASAuthorizationController с oneTimeCode на iOS.

JWT: access и refresh токены

Паттерн: короткоживущий access token (15 минут – 1 час) + долгоживущий refresh token (30–90 дней). Access token в памяти (in‑memory — не в Keychain), refresh token в Keychain/EncryptedSharedPreferences. Silent refresh: при получении 401 — автоматический запрос нового access token с refresh token. Если refresh token истёк — принудительный логин.

Rotation refresh tokens: каждый обмен refresh token на access token выдаёт новый refresh token. Старый инвалидируется. Если старый refresh token попытался использоваться — компрометация, все токены пользователя отзываются.

Что входит в работу

При заказе модуля аутентификации мы предоставляем:

• Исходный код модуля авторизации (Swift/Kotlin) с интеграцией выбранных методов.
• Документацию по архитектуре и схеме токенов.
• Настроенный PKCE‑флоу для OAuth 2.0.
• Интеграцию Sign in with Apple и Google Sign-In по вашим client_id.
• Конфигурацию биометрии с правильными protection‑флагами.
• Инструкцию по деплою и тестированию (TestFlight, Firebase App Distribution).
• Чек‑лист для прохождения ревью App Store и Google Play.

Сроки и стоимость

Реализация базовой аутентификации (email + пароль + JWT) занимает от 1 до 2 недель. Добавление OAuth, биометрии и 2FA — ещё 1–3 недели. Итоговая стоимость рассчитывается после аудита вашего проекта. Получите консультацию — мы оценим сложность и предложим оптимальный стек.

Типичные ошибки (и как их избежать)

• Хранение токенов в UserDefaults / SharedPreferences — читаются без root на рутованных устройствах. Решение: Keychain / Keystore.
• Отсутствие certificate pinning в high‑security приложениях — MITM через корпоративный proxy. Решение: добавляем pinning в URLSession или OkHttp.
• Хранение секретов в Info.plist или BuildConfig — декомпилируются тривиально. Решение: использовать Keychain или серверную конфигурацию.
• OAuth через WKWebView / WebView вместо системного браузера — rejection App Store + security risk. Решение: ASWebAuthenticationSession / Custom Tabs.
• Неправильный kSecAttrAccessible — токен с kSecAttrAccessibleAlways не требует разблокировки устройства. Решение: WhenUnlockedThisDeviceOnly.

Мы реализовали безопасную аутентификацию для 30+ проектов за 5 лет работы. Гарантируем соответствие требованиям платформ и лучшим практикам (OAuth 2.0 + PKCE, Keychain, Keystore). Закажите разработку модуля аутентификации — разберём уязвимости и предложим решение под ваш бюджет. Получите консультацию через форму на сайте.