2017-01-23 3 views
3

Я борюсь с концепцией разработки API аутентификации RESTful без аутентификации с многофакторной аутентификацией.Как создать автономный вход REST с 2 аутентификацией фактора (2FA)?

Практически по определению потребность в 2FA требует нескольких состояний; вход в систему с именем пользователя/паролем, а затем отправкой «кода» (либо TOTP, SMS-код, ответ на вопрос проверки и т. д.). Это дополнительно подразумевает конечную машину (FSM).

Насколько я могу сказать, единственные варианты, которые существуют для того, чтобы поддерживать механизм без гражданства являются:

  1. клиент должен передать некоторую информацию о состоянии (например: текущее FSM состояния) при представлении данных в переход к следующему состоянию,
  2. государство должно сохраняться на стороне сервера,
  3. клиент должен передавать все данные по каждому запросу, что позволило ему достичь текущего состояния

Очевидно, что передача всех данных бессмысленна. Таким образом, это подразумевает передачу информации о состоянии (непрозрачной или другой) в состоянии запроса или сохранения на сервере.

Или есть какая-то другая техника, которую мне не хватает?

+0

Я бы посмотрел с архитектурной точки зрения на то, как структуры AWS 2FA в своем продукте аутентификации Cognito. Кроме того, я знаю, что с точки зрения потребления каждый следующий уровень активности с API требует, чтобы я проходил комбинацию данных. поэтому, к концу, я отправляю такие вещи, как токен сеанса, мой телефонный код, плюс мой оригинальный объект auth и т. д. Вы можете найти что-то полезное там – Kristian

+0

@ Eric B. Вы нашли ответ для этого. Если да, можете ли вы, пожалуйста, сообщить мне об этом. Заранее спасибо. –

+0

@NickDiv Я опубликовал решение, с которым я пришел. Пожалуйста, дайте мне знать, если это ясно или вам нужна дополнительная информация. –

ответ

2

Я добавляю решение, которое я придумал, если это выгодно для кого-то еще в будущем. Обратите внимание, что в этом случае PVQ означает «персональный вопрос валидации» (то есть: аутентификация на основе знаний).

В конце концов, я разработал свой логин конечной точки требуется:

  • Authorization заголовок (который является маркером 2fa): Authorization: authType=”PVQ” token=”<tokenid>”
  • имя пользователя
  • пароль

Если в Authorization заголовок отсутствует, конечная точка возвращает 401 и устанавливает заголовок WWW-Authenticate, указывая, что для входа требуется токен 2FA (то есть: заголовок авторизации).пары могут быть PVQ, SMS, TOTP и т.д. (в зависимости от конфигурации пользователя)

WWW-Authenticate : authType="PVQ" 

Если клиент получает 401/WWW-Authenticate ответа, это его ответственность называть 2fa конечных точек:

  • вызов/получить (получить токен вызов)

    • Клиент: отправляет имя пользователя/пароль
    • Сервер: реагирует с идентификатором, и либо
      • вопрос (PVQ)
      • или просто посылает посылает код SMS через третьи партии поставщика SMS
  • вызов/проверить (получать 2fa Токен нужен для заголовка Authorization)

    • Клиент: посылает
      • ID полученные в challenge/get
      • имя пользователя/пароль
      • ответ на вызов (т.е. текст ответа на PVQ или SMS-код, или TOTP код)
    • Сервер: возвращает
      • 2fa маркер значение

Клиент теперь может вызывать конечную точку входа с обязательным: токеном пользователя/паролем/аутентификацией.

В конце концов, не существует «состояния», согласно которому клиент возвращается на сервер, но компромисс для этого заключается в том, что комбинация имени пользователя и пароля должна быть отправлена ​​на каждый запрос для подсистемы 2FA.

На стороне сервера имеется некоторая информация о состоянии, хранящаяся в БД, в контексте кода SMS или PVQ, который был отправлен пользователю, а также эфемерного токена аутентификации 2FA (однократное использование и фиксированный TTL).

Смежные вопросы