Блог

Фон

Мы разработали CMS в ASP.Net Ядро 2.2 появилось несколько лет назад для внутренних повседневных задач компании. Он вмещает несколько сотен пользователей, и я рассматриваю возможность добавления в него приложения для Android. Приложение для Android должно в основном служить в качестве интерфейса для существующей логики в ASP.Net контроллеры. Преимущества приложения для Android, которое я ожидаю, заключаются в том, что:

• Лучше UX
• Пользователю не нужно вводить пароль для каждого сеанса (ASP.Net страница выводит их из системы после 20 или 30 минут бездействия)
• Push-уведомления и т.д.

Существующая инфраструктура

CMS уже имеет API (JWT), который используется несколькими серверными службами и может быть легко расширен для использования каждым пользователем через приложение для Android. К сожалению, я не являюсь профессиональным разработчиком в целом и особенно новичком в Java, поэтому, пожалуйста, проявите немного терпения, поскольку я прошу общего совета о том, как обрабатывать аутентификацию в приложении для Android (Java).

Я читал о curity.id и тому подобное, но ИМО это было бы своего рода излишеством для всего проекта, а также потребовало бы серьезных изменений в уже работающем прекрасном ASP.Веб-сайт в сети.

Теперь мой вопрос заключается в том, будет ли приемлемой практикой следующее:

1. Когда пользователь открывает приложение в первый раз, я спрашиваю у него имя пользователя и пароль (и, возможно, 2-й фактор).
2. Я делаю http-запрос к API CMS, чтобы аутентифицировать пользователя и вернуть токен JWT при успешной аутентификации.
3. Токен JWT каким-либо образом сохраняется (например, в базе данных SQLite) и используется для последующих запросов, выполняемых к API.
4. Поскольку срок службы токена JWT также ограничен несколькими часами, и цель состоит в том, чтобы приложение работало без постоянного запроса учетных данных пользователя, мне также нужно каким-то образом сохранить пароль в приложении или базе данных на устройстве Android. На самом деле это та часть, которая меня больше всего смущает, и я понятия не имею, как я буду хранить пароль безопасным способом, чтобы его можно было снова использовать для запросов на аутентификацию в будущем. (Я знаю, что если пользователь использует 2-й фактор, нет другого выхода, кроме как запрашивать 2-й фактор каждый раз, когда истекает срок действия токена, или исключать устройство или что-то в этом роде, но это не должно входить в рамки этого вопроса)

Поэтому я был бы признателен за некоторые суждения об этом подходе, если он приемлем в целом и что было бы наилучшим способом сделать с пунктом № 4.

Большое спасибо

Не храните пароль

Если вы храните (и часто отправляете) пароли, вы нарушаете всю цель токена. Сам токен существует как одноразовое средство для замены первичной аутентификации (однако он достаточно криптографически надежен, чтобы заменить его без снижения безопасности системы).

ПРОСТО: Используйте длинный токен

Создайте новый API аутентификации (или добавьте некоторые параметры к существующему), чтобы мобильному приложению требовался токен длительного действия (например, 6 месяцев). Если вы затем сохраните этот токен в SecureStorage устройстве, вы можете быть совершенно уверены, что он не может быть извлечен оттуда.

Помните, что с помощью этого решения вы теряете контроль над аутентификацией. Это не лучшая практика, но это самое простое решение для использования в случае существующих инфраструктур JWT, которые используют только один токен.

РЕКОМЕНДУЕТСЯ: Создать систему токенов обновления

Как только вы выпустили токен, вы не можете его отозвать. Следовательно, основная проблема, связанная с решением «длинный токен», заключается в том, что в случае утери устройства его нельзя деаутентифицировать. Это может быть решено с помощью токена продления:

• Вы создаете API аутентификации , который после подтвержденной аутентификации создает уникальный sessionId , сохраняет его в базе данных и выдает специальный токен, содержащий sessionId , помимо прочего, информацию. Это называется токеном продления. Этот специальный токен можно использовать только для API exchange
• Затем вы создаете API exchange, который ожидает токен обновления в обмен на обычный токен (который может обладать теми же свойствами, что и ваш текущий токен). Этот API всегда будет проверять sessionId , по-прежнему ли токен обновления помечен в базе данных как активный, в противном случае обычный токен не будет выдаваться.

Этот подход позволяет вам иметь токены с очень длительным сроком действия, но при этом иметь возможность удаленно выходить из приложения (маскируя sessionId как деактивированное в базе данных) и даже отслеживать, как часто используется приложение.