Мобильная аутентификация с использованием QR в веб-приложении - PullRequest
0 голосов
/ 28 декабря 2018

У меня есть сомнения относительно правильной схемы следующего технического решения.Мне нужно подтвердить подлинность пользователя в мобильном приложении, прочитав QR-код, причем пользователь предварительно прошел проверку подлинности в веб-приложении.

Вариант использования состоит в том, что пользователь использует веб-приложение, расположенное в интрасети, нодолжен иметь возможность загружать изображения с мобильного устройства, которое будет подключено к Интернету.Мобильное приложение будет использовать публичный API, предоставляемый в Интернете через API-шлюз.API-шлюз подключится к бэкэнду для загрузки изображений.В качестве требования, когда пользователю необходимо использовать мобильное устройство для захвата и загрузки изображений, они не должны снова проходить аутентификацию, поскольку у них есть открытый сеанс в веб-приложении, и просто используют QR-код для аутентификации устройства.Логически QR не будет использовать учетные данные пользователя.

Моя идея состоит в том, чтобы использовать Oauth 2.0 со следующим потоком для аутентификации мобильного устройства:

  1. Веб-приложение запрашивает шлюз API длясгенерируйте токен авторизации, и он ответит UUID.
  2. Веб-приложение отобразит токен авторизации, используя QR, полученный от шлюза API.
  3. Мобильное устройство прочитает QR и запроситтокен доступа к Шлюзу API с токеном авторизации.
  4. Шлюз API проверяет токен авторизации и генерирует токен доступа, который возвращается на мобильное устройство.
  5. Мобильное устройство выполняет вызовыобщедоступный API (API Gateway) с использованием токена доступа.

У меня вопрос: правильная ли это схема или есть другое стандартное решение?

Спасибо !!

Ответы [ 3 ]

0 голосов
/ 11 января 2019

Вы можете использовать FireBase ML Kit для хорошего решения, и он также может выполнять множество функций на основе AI для ваших приложений.Вы можете проверить это здесь: https://firebase.google.com

0 голосов
/ 14 января 2019

Ваша схема будет работать, НО она не достигает своего полного потенциала безопасности, учитывая тот факт, что вы можете перенести новый сгенерированный токен авторизации с уже авторизованного устройства напрямую на другое (через QR-код, считываемый камерой);этот факт сделает шаги 3 и 4 ненужной уязвимостью (это также избыточность, уже есть токен !, зачем нужен другой?);

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

замена шага 3: прочитайте токен авторизации;

замена шага 4: проверьте безопасный вывод хеш-кода токена авторизации (вместо самого токена) с сервером, чтобы убедиться, что он действителен;

token0=read_auth_token_from_camera()
public_token=hash_function(token0) //the useless exposed token
if(check_token_with_server_for_authenticity(public_token)==true)
    continue_to_step_5() //it's authorized
else
    handle_the_scenario()

замена шага 5: зашифруйте ваш запрос и токен авторизации с помощью другого хеш-кода для токена авторизации, затем выполните вызовы к API сервера;

token2=another_hash_function(token0)
request="i am top secret data"
encryption_key=token0
encrypted_request=encryption_function( token2 + request , encryption_key)
send_to_server( public_token+encrypted_request)
//notice that token2 is unknown to the intruder because its encrypted,but it is known to the server; hence the authenticity of each request can be checked by the server;

как это более безопасно: вэтот альтернативный способ фактического токена авторизацииникогда не обменивается между сервером и новым клиентом;Поэтому, если злоумышленник может гипотетически нарушить уровень SSl / TLS и перехватить общедоступный токен, злоумышленник не сможет отправлять какие-либо запросы от вашего имени или изменять данные в запросах;

0 голосов
/ 10 января 2019

Если эта схема удовлетворяет желаемому потоку приложений, то это правильно.Это не стандартный способ аутентификации Android-устройств, если вы собираетесь самостоятельно сделать аутентификацию.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...