Как правильно хранить сессию при разработке JSON API?
Обычно мы храним id сессии в cockie браузера. Но допустим я хочу использовать свое API в мобильных приложениях ios/android, и я собираюсь хранить куку в памяти приложения и вставлять потом в каждый запрос с приложения. Но на сколько это правильно? Есть ли какие-то советы по этому поводу?
Авторизация по токену.
При аутентификации отдаем клиенту его токен.
Он его посылает, скажем через заголовки: X-Access-Token: bla bla bla
И на сервере проверяете.
Разумеется, не поленитесь https для такого дела поднять.
1. Авторизуетесь и получаете токен (он же и есть ID-сессии).
2. Подписывайте этим токеном запрос к API (хэшируете) и отправляете запрос с токеном на сервер: в отдельном заголовке или как один из параметров при вызове API (лично я - предпочитаю 2-й вариант (аналог jwt): шифровать и тестить мне проще).
Допустим авторизовываюсь, и сервер мне шлет id сессии в таком виде - s%3A5OaRjPkBLOCCaZa5qdUnN_MaMYhfQeuW.6oGe%2BTpu7ZaLhvNpjrTwksS9uKAmVFZhTYfolEwrKJU - это уже подписанная сессия (так сейчас хранится сессия в куке браузера). В таком случае мне нужно что-то еще подписывать на клиенте? Можете шаг #1 и #2 поподробнее изложить с примером заголовков? Не очень понятно в каком виде, в какой момент и что именно я должен получить от сервера, и что сделать на клиенте.
Al: нет такого понятия как "подписанная сессия". сессия или анонимная или авторизованная, а запрос - подписанный.
Советую почитать (погуглить) основные принципы создания API для сервисов.
xmoonlight: Я понял, единственный вопрос, о том как проверить подписанный токен
Подписываем этим токеном запрос к API (хэшируем: передаём дополнительный параметр HASH) и отправляем запрос (с параметрами API, токеном, хэшем и случайной строкой) на сервер.
Вот пришли на сервер данные с клиента (хэшированный токен и случайная строка), как верифицировать его?
xmoonlight: Если на клиенте виден механизм генерации хеша, и такой же механизм используется на сервере, то какой вообще с этого смысл? чем это отличается от не подписанного запроса (если просто передавать id сессии в отдельно заголовке)?
xmoonlight: да понимаю, но для чего его применяют здесь? что это дает?
Я так понял мы чтото хэшируем на клиенте, передаем это на сервер, и дальше, что происходит на сервере с хэшем и остальными данными полученными от клиента и что это нам дает?
xmoonlight: Клиент запрашивает страницу, сервер отдает ему токен (id сессии), далее клиент хочет авторизоваться - он шлет в отдельном заголовке этот токен и данные для авторизации, на сервере данные верифицируются, в случае успеха клиент со этим токеном может слать другие запросы на хост с этим api.
Здесь, до меня никак не дойдет, зачем мне каждый раз чтото хэшировать на клиенте и потом проверять это на сервере, и как это делать в частности на сервере? - ну например я склеил токен + timastamp + еще чтото, прогнал это через какойто например md5, попало это на сервер, ну и дальше что? как разбирать? зачем это? и что это даст?
Al: мда... смотрите:
hash - это подпись Вашего запроса (аналог того, как Вы ставите подпись ручкой в документе).
То, под чем Вы расписываетесь - это параметры.
Чтобы проверить, что запрос к API выполнили именно Вы, передаёте на сервер:
параметр1,..,параметрN, hash, token, timestamp, random - вот эти параметры - передаются все в открытом виде (т.е. как есть)!
Пример формулы (*) формирования HASH на клиенте: HASH=md5(параметр1.параметрN.token.timestamp.random.password)
password - сервер знает и пересылать его не нужно!
Сервер получает этот запрос и сверяет время timestamp со своим серверным: что запрос не просрочен более, чем на сутки. (можно еще записывать в таблицу вызовов API и проверять уникальность запроса по HASH+token и частоту обращений к API, если это необходимо)
И после базовой проверки - проверяет HASH:
Берёт все параметры и создаёт HASH у себя по той же самой формуле (*) из присланных параметров и получает свой вариант SHASH (server-hash).
Затем - сравнивает абсолютно: if (HASH===SHASH) => если да: значит исполняет запрос, нет - генерит ошибку.
xmoonlight: хорошо, тут у меня появилось несколько вопросов, может идиотские, но все же.
1. параметр1 параметрN - что именно это за параметры? Это просто какието данные вроде page=1&order=id ?
2. timestamp - это время в секундах которое обозначает дату когда был выполнен запрос с клиента?
3. password - это какаято статическая строка которая одинакова на сервере и клиенте или это чтото уникальное для конкретного пользователя, если да - что именно?
Сервер получает этот запрос и сверяет время timestamp со своим серверным
4. Это значит что мы шлем timestamp отдельным параметром?
5. Отсюда вытекает что и random мы тоже шлем отдельным параметром?
Теперь, на сервере после базовой проверки
Берёт все параметры и создаёт HASH у себя по той же самой формуле (*) из присланных параметров и получает свой вариант SHASH (server-hash).
6. Раз мы ему передали все параметры по отдельности в т.ч. random, а password одинаков для всех клиентов, то какова суть вообще проверки хэша? Ведь тогда достаточно сверить timestamp если есть необходимость и все.
Al: еще забыл, по предотвращению повторных запросов:
1. Создаёте таблицу исторических запросов к API и логируйте каждый запрос, затем - проверяете по ней уникальность. (лучше, но медленнее)
2. ИЛИ/И Привязывайте сессию (токен) к IP-адресу клиента (хуже, но быстрее).
Лучше - сразу оба метода использовать.
Ну и всё это (весь обмен данными) - лучше шифровать данными авторизации/токеном.
А уже после - обернуть в SSL.
Al:
1. да, параметры API
2. да
3. password - это учётка юзера, например md5(login+pass), для авторизации
4. да, мы шлём ВСЕ параметры, кроме password
5. да, см. п.4
6. если пароль для всех клиентов одинаков (или он пустой), значит вы используете АНОНИМНЫЙ ДОСТУП, но обычно к API выдаются учётные данные для каждого клиента по-отдельности.
Если доступ к API - АНОНИМНЫЙ, то необходимо получить SKEY (который и будет тем же password-ом на клиенте) от сервера заранее или при авторизации.
SKEY - генерится сервером любым известным только серверу алгоритмом (случайным или НЕ случайным - неизвестно: можно сделать как угодно).
Только тогда обязательно нужно вводить время жизни токена (и делать его по-меньше: сутки достаточно), привязку токена к IP и контроль уникальности ВСЕХ запросов - тут однозначно ЕДИНАЯ историческая таблица запросов к API от всех клиентов.
Al: добавка: при АНОНИМНОМ доступе к API Вы сможете лимитировать только по IP-адресу! (по токену - уже не сможете, т.к. его не к чему привязать на сервере: нет уникальной учётки => нельзя идентифицировать конкретного клиента!)
xmoonlight: спасибо) уже есть просветление)
еще вопрос по поводу пароля, например на сервере, при авторизации я получаю пароль в виде "1111", потом хеширую его с помощью bcrypt, потом результат хэша подписывается ключом для подписи сессий и в куку в браузере сохраняется чтото вроде этого: %242y%2410%24zDIKIWaF3Kg6Rlee6x0JtuV6rp4j2d83YMcpeIGF3dAuyidTBJoIq
Когда сессия умрет, клиент может заново авторизоваться по этой куке + кука с id юзера.
Собственно, вопрос в том, password на клиенте я должен хранить как "login+1111" или как "login+%242y%2410%24zDIKIWaF3Kg6Rlee6x0JtuV6rp4j2d83YMcpeIGF3dAuyidTBJoIq" ? В это же время, пароль в сессии я храню в таком виде без подписи как он есть в бд: "$2y$10$zDIKIWaF3Kg6Rlee6x0JtuV6rp4j2d83YMcpeIGF3dAuyidTBJoIq".
Как будет более правильно? (я думаю вариант с подписанным значением)
Al: password = это хэш учётных данных пользователя! Понимаете, что сервер может не знать Ваше имя пользователя и Ваш пароль) Он может лишь знать Ваш ID и HPASS=password = hash(login.pass.SALT). А SALT ("соль") - единый для всего у сервера.
В итоге, в базе - нельзя понять соответствие аккаунта и пароля к нему тогда, когда стащат базу!)
Т.е. 2 таблицы: AUTH и USERS.
В AUTH - храним ID и HPASS (тот, что у нас в обсуждении: password)
В USERS - храним ID, username, firstname, lastname и т.д.
После прохождения авторизации - работаем только с таблицей USERS.
Пароль в сессии (пусть и парольный хэш) - хранить смысла нет: получили из базы, проверили и сразу забыли.
Al: пароль на клиенте - лучше НИКОГДА не хранить! Хранить только TOKEN АВТОРИЗАЦИИ! Если сервер сказал, что TOKEN просрочен/недействителен - выдавать диалог пользователю на ввод учётных данных.
xmoonlight: Я так понял что на клиенте password мы храним в таком виде "%242y%2410%24zDIKIWaF3Kg6Rlee6x0JtuV6rp4j2d83YMcpeIGF3dAuyidTBJoIq", шлем это на сервер и при каждом запросе сверяем соответствие, потом на сервере складываем все и сверяем, так?
Al: мы ВООБЩЕ НИКОГДА не пересылаем password на сервер!
Мы пересылаем только HASH и все остальные параметры!
На сервере мы никогда не сверяем отдельно хэши, содержащие учётные данные, т.к. мы НЕ ПЕРЕДАЁМ ИХ!
Сверяются только общие хэши: HASH (где мы берём от клиента все параметры, кроме password) и SHASH (где password - берём из БД).
xmoonlight: да, в теории вроде все легко и понятно, но детали сложны. Если сделаете пост в блоге это будет супер. Киньте ссылку обязательно если сделаете. И большое вам спасибо за растолкование темы)
Простой
