История изменений

Планирую сейчас блюпринты, потом пойду в django

Не знаю насчёт flask, но джанга всегда будет сохранять кусок юзера в свою базу при аутентикации в ldap. Она не должна дать зайти если юзер из ldap удалён на момент входа, но если есть старая сессия — её никто не убьёт. Без своей модели в джанге нельзя (вообще никак) потому, что в очень многих местах ожидается foreign key на settings.AUTH_USER_MODEL, поэтому, очевидно, таблица с этой AUTH_USER_MODEL обязана быть в той же базе, что и всё остальное приложение.

я ее кеширую вместе с юзером в sql.

Если flask сделан нормально — он не должен кэшировать пароль и должен обновлять копию в твоей rdbms каждый раз когда юзер вводит этот самый пароль.

Или как мне очищать sql от юзеров по таймауту?

Убедись, что твоя проблема — не в сессиях. Судя по твоему вопросу, она именно там.

Ты можешь добавить лишнюю проверку статуса в ldap при подхвате сессии с юзером, это решит все проблемы (ну, у тебя добавится 1 запрос в ldap на буквально каждый HTTP-запрос, но иногда это может быть ок решением).

Но почему я не могу просто и сразу прямо использовать ldap в качестве базы юзеров? без sql или каких-то костылей?

Потому, что foreign key и транзакции между двумя разными базами данных (твоя rdbms и LDAP) — ОЧЕНЬ сложные вещи и django/flask не заморачиваются ими.

Но так же это приведет к лагам между изменением в open-ldap и реакции приложения на эти изменения:

Потому, что у тебя распределённая система и твоя проблема — на выбор — инвалидация кэша либо распределённые транзакции. Прямой способ решить всё это — не делать систему распределённой (= хранить все разрешения и роли в ldap), тогда ты потеряешь возможность управлять юзерами средствами flask/django. И да, тебе придётся переписать весь auth-кусок этих фреймворков поскольку навскидку готового решения (без копирования информации из ldap) я не помню. Я бы посоветовал вместо этого пользоваться костылями, если честно.

Планирую сейчас блюпринты, потом пойду в django

Не знаю насчёт flask, но джанга всегда будет сохранять кусок юзера в свою базу при аутентикации в ldap. Она не должна дать зайти если юзер из ldap удалён на момент входа, но если есть старая сессия — её никто не убьёт. Без своей модели в джанге нельзя (вообще никак) потому, что в очень многих местах ожидается foreign key на settings.AUTH_USER_MODEL, поэтому, очевидно, таблица с этой AUTH_USER_MODEL обязана быть в той же базе, что и всё остальное приложение.

я ее кеширую вместе с юзером в sql.

Если flask сделан нормально — он не должен кэшировать пароль и должен обновлять копию в твоей rdbms каждый раз когда юзер вводит этот самый пароль.

Или как мне очищать sql от юзеров по таймауту?

Убедись, что твоя проблема — не в сессиях. Судя по твоему вопросу, она именно там.

Ты можешь добавить лишнюю проверку статуса в ldap при подхвате сессии с юзером, это решит все проблемы (ну, у тебя добавится 1 запрос в ldap на буквально каждый HTTP-запрос, но иногда это может быть ок решением).

Но почему я не могу просто и сразу прямо использовать ldap в качестве базы юзеров? без sql или каких-то костылей?

Потому, что foreign key и транзакции между двумя разными базами данных (твоя rdbms и LDAP) — ОЧЕНЬ сложные вещи и django/flask не заморачиваются ими.

Но так же это приведет к лагам между изменением в open-ldap и реакции приложения на эти изменения:

Потому, что у тебя распределённая система и твоя проблема — на выбор — инвалидация кэша либо распределённые транзакции. Прямой способ решить всё это — не делать систему распределённой (= хранить все разрешения и роли в ldap), тогда ты потеряешь возможность управлять юзерами средствами flask/django. И да, тебе придётся переписать весь auth-кусок этих фреймворков поскольку навскидку готового решения (без копирования информации из ldap) я не помню.