Запрос обратной связи: многоэтапная аутентификация API с использованием нескольких конечных точек - PullRequest
Новая
       39

Запрос обратной связи: многоэтапная аутентификация API с использованием нескольких конечных точек

0 голосов
/ 03 ноября 2018

Я создаю API, который будет аутентифицироваться с использованием следующего потока.

Endpoints:

  • WWW:/login - это интерфейс HTML5, использующий ajax-вызовы JS
  • API:/check_password - проверка комбо адреса электронной почты / пароля.
  • API:/check_otp - проверяет OTP (одноразовый пароль) для пользователя.
  • API:/login - устанавливает cookie сеанса аутентификации

Предположение:

  • API:/check_otp будет вызываться всегда и только после API:/check_password.
  • Игнорировать атаки CSRF и XSS.
  • Даже если интерфейс (WWW: / login) является вредоносным, API будет работать только с действительными учетными данными и / или action_tokens.
  • Мне известны OAuth2, JWT и RESTful API. Мой вопрос не о RESTful API.

При входе в систему поток будет следующим:

  • WWW:/login отправляет электронную почту и пароль на API:/check_password.

  • Если учетные данные действительны, API:/check_password вернет action_token и mfa_status (обозначает многофакторную аутентификацию).

    • Если mfa_status равно 0, это означает, что MFA не включен.
    • Если mfa_status равно 1, это означает, что MFA включен.

  • Если (mfa_status === 1), то WWW: / login вызовет API:/check_otp и передаст ему action_token, полученный от API:/check_password, а также OTP.

    • Если OTP и action_token действительны, то API:/check_otp вернет новое action_token.
  • Если (mfa_status === 0) или API:/check_otp вернет действительный action_token, то WWW:/login вызовет API:/login и передаст ему email и action_token.

Для меня это означает, что веб-интерфейсу НЕ нужно сохранять пароль или OTP где-либо в своих хранилищах данных (localstorage, indexeddb и т. Д.). Это также означает, что он может немедленно удалить action_token из своих хранилищ данных.

ВОПРОСЫ:

  1. Это безопасно?
  2. Есть ли недостатки в этой логике?
  3. Я что-то пропустил?

Большое спасибо за интересное и обстоятельное обсуждение!

1 Ответ

0 голосов
/ 03 ноября 2018

Ваш шаблон напрямую отображается на OAuth2, почему бы вам не использовать проверенный и надежный шаблон безопасности, такой как OAuth2? Вы пытаетесь восстановить его по какой-то причине ... ваш action_token совпадает с маркером доступа OAuth.

Кроме того, вам потребуется сохранить маркер доступа для последующих вызовов к защищенным ресурсам (вы знаете, как это делает OAuth) ...

Все, что вы делаете, - это выполняете для себя больше работы, не используя либо готовую библиотеку OAuth, либо запутывая процесс, чтобы следующий человек с аппетитом обновил этот код вместе с вами.

...