Обзор

Я хочу создать (REST) ​​API для своего приложения. Первоначальная / основная цель - потребление мобильными приложениями (iPhone, Android, Symbian и т. Д.). Я изучал различные механизмы аутентификации и авторизации для веб-API (изучая другие реализации). Я хорошо разбираюсь в большинстве фундаментальных концепций, но все еще ищу руководство в некоторых областях. Последнее, что я хочу сделать, это изобретать велосипед, но я Я не могу найти никаких стандартных решений, соответствующих моим критериям (однако мои критерии могут быть ошибочными, так что не стесняйтесь критиковать и это). Кроме того, я хочу, чтобы API был одинаковым для всех платформ / приложений, использующих его.

oAuth

Я продолжу и выскажу свое возражение против oAuth, поскольку я знаю, что это будет первое предложенное решение. Для мобильных приложений (или, точнее, не веб-приложений) кажется неправильным оставлять приложение (переходить в веб-браузер) для аутентификации. Кроме того, у браузера нет способа (я знаю) вернуть обратный вызов приложению (особенно кроссплатформенному). Я знаю пару приложений, которые это делают, но это кажется неправильным и мешает UX приложения.

Требования

1. Пользователь вводит имя пользователя / пароль в приложение.
2. Каждый вызов API идентифицируется вызывающим приложением.
3. Накладные расходы сведены к минимуму, а аспект аутентификации интуитивно понятен для разработчиков.
4. Механизм безопасен для обоих конечных пользователей (их учетные данные не раскрываются ), а также разработчик (их учетные данные приложения не раскрываются).
5. Если возможно, не требовать https (ни в коем случае не жесткое требование).

Мои текущие мысли о реализации

Внешний разработчик запросит Аккаунт API. Они получат апикей и аписекрет. Каждый запрос требует как минимум трех параметров.

• apikey - предоставляется разработчику при регистрации
• timestamp - дублируется как уникальный идентификатор для каждого сообщения для данного хэша apikey
• - хеш временной метки + apisecret

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

Для аутентифицированных запросов (выполняемых от имени пользователя) я все еще не могу выбрать между маршрутом access_token или хешем имени пользователя и пароля. комбо. В любом случае, в какой-то момент потребуется комбинация имени пользователя и пароля. Поэтому, когда это произойдет, будет использоваться хеш из нескольких частей информации (apikey, apisecret, timestamp) + пароль. Я хотел бы получить отзывы по этому поводу. К вашему сведению, им придется сначала хешировать пароль, поскольку я не храню пароли в своей системе без хеширования.

Заключение

К вашему сведению, это не ' та запрос о том, как построить / структурировать API в целом, только как обрабатывать аутентификацию и авторизацию исключительно из приложения.

Случайные мысли / дополнительные вопросы

Для API, которые требуют только apikey как часть запроса, как сделать так, чтобы кто-то, кроме владельца apikey, не мог видеть apikey (поскольку он был отправлен в открытом виде) и делать чрезмерные запросы, чтобы подтолкнуть их к пределам использования? Может быть, я просто над этим подумал, но разве не должно быть чего-то, что могло бы подтвердить, что запрос был подтвержден владельцем apikey? В моем случае это было целью apisecret, он никогда не отображается / не передается без хеширования.

Кстати о хэшах, а как насчет md5 vs hmac-sha1? Имеет ли значение, когда все значения хешируются с достаточно длинными данными (т.е. apisecret)?

Ранее я подумывал о добавлении соли для каждого пользователя / строки в хэш пароля пользователя. Если бы я сделал это, как могло бы приложение создать соответствующий хеш, не зная, какая соль используется?