Подтвердить что ты не робот

REST-аутентификация и HMAC/закрытый ключ (когда я его установлю?)

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

До сих пор я понял, что лучший способ сделать это - это реализация HMAC, подобная той, которая используется Amazon.

Моя самая большая проблема заключается в том, как я могу, например, проверить подлинность пользователя и предоставить им свой закрытый ключ, чтобы они могли начать подписывать HMAC? Я продолжаю читать, что закрытый ключ, используемый для подписания HMAC, не должен отправляться по проводному когда-либо, но как же они когда-либо получат его в первую очередь?

Моя идея была чем-то вроде этого, но я не уверен, что это действительно.

Таблица базы данных для пользователей:

users (simplified, this would probably be a private key per client app?)
  id (their public key?)
  username
  password?
  privatekey

Предполагая, что клиент HTML/JS пользователь будет иметь традиционную страницу входа в систему, которая POST для API будет выглядеть примерно так:

https://example.com/myapp/api/v1/authenticate.json
POST: username / password

Это вернет либо

404:User not found
200:{ "id" : <id>, "privatekey": <privatekey> }

Затем клиент будет хранить этот ключ где-нибудь (будет ли локальное хранилище/файл cookie безопасным местом?) и использовать его для подписи дополнительных запросов, которые будут выглядеть следующим образом:

GET https://example.com/myapp/api/v1/something/?key1=value1&publickey={theirID}&hmac={hmac signature of the request using their private key}

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

Я правильно понял? Я не уверен, что понимаю роль частного ключа, если мне все еще нужен пароль, как в моем примере, поэтому что-то говорит мне, что я могу ошибаться.

4b9b3361

Ответ 1

Я думаю, вам нужно предоставить более подробную информацию о вашем приложении и о том, как он будет использоваться. Существует много способов аутентификации REST. Некоторые из них являются стандартными, а некоторые нет. Это лишь некоторые примеры:

В случае Amazon S3 они выдают вам секретный ключ доступа AWS при регистрации. Позже ваш код приложения должен знать секретный ключ, чтобы иметь возможность вычислять подписи (или он должен знать подписанный запрос/URL-адрес) Таким образом, в конечном счете "секретный ключ доступа" передается по проводу, по крайней мере, один раз вначале во время регистрации.

Если вы используете криптографию с открытым ключом (например, SSL-сертификаты клиента), вы можете вообще не передавать общий ключ

  • вы создаете открытый/закрытый ключ на клиенте
  • Отправить открытый ключ на сервер (или сертификат, подписанный доверенным органом)
  • Запросы подписи (или nonces) с закрытым ключом и сервером проверяют подпись с помощью открытого ключа.

Если ваша цель - просто аутентифицировать запросы AJAX, сделанные на вашем сайте после того, как пользователь выполнил аутентификацию на странице входа в систему - вы можете просто использовать файлы cookie, подписанные сервером.