Создание Server side session аутентификации с сохранением токена в куки клиента

Склонируйте репозиторий на вашу локальную машину:
```
git clone https://github.com/Jhnvlglmlbrt/server-side-session-auth
```
Перейдите в директорию проекта:
```
cd server-side-session-auth
```
Установить зависимости:
```
go get 
```
Запустите код:
```
make run
```

Запросы к ручкам:

POST http://localhost:8080/signin

{"username":"user2","password":"password2"}

GET http://localhost:8080/welcome

POST http://localhost:8080/refresh

GET http://localhost:8080/logout

Структура приложения

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

Т.к. мы не можем хранить пароли наших пользователей в том виде, в котором их получаем. Нужно преобразовать каждый пароль таким образом, чтобы его было легко проверить , но нелегко угадать.

Для этого будет использоваться функция хеширования (алгоритм bcrypt). Преимущество в том, что легко преобразовать фрагмент текста в хеш, но почти невозможно угадать фрагмент текста по хешу.

Во время входа в систему можем проверить правильность пароля для данного имени пользователя, получив хэш пароля для этого имени пользователя и используя функцию сравнения bcrypt для проверки данного пароля с помощью хеша:

/signup примет учетные данные пользователя и надежно сохранит их в нашей базе данных.

/signinбудет принимать учетные данные пользователя и аутентифицировать их, сравнивая их с записями в базе данных.

Теперь схемы ниже должны чуть поменяться - данные будут храниться не в map в коде,а в бд. И входить нужно будет только по 1 пользователю.

Если пользователь успешно входит в систему, этот обработчик установит файл cookie на стороне клиента и в своей локальной памяти. Как только файл cookie установлен на клиенте, он отправляется вместе с каждым последующим запросом.

Теперь, когда информация о сеансе пользователя на его клиенте сохранена (в форме файла session_token cookie) и на сервере, напишем обработчик «приветствия» для обработки информации, специфичной для пользователя.

Из кода мы видим, что наш обработчик приветствия дает нам 401 статус «неавторизованный» (или ) при определенных обстоятельствах:

session_tokenЕсли вместе с запросом нет файлов cookie (это означает, что запрашивающая сторона не входила в систему)
Если токен сеанса отсутствует в памяти (это означает, что запрашивающая сторона отправляет нам недопустимый токен сеанса)
Если срок сеанса истек

Аутентификация на основе сеанса обеспечивает безопасность сеансов ваших пользователей несколькими способами:

Поскольку токены сеанса генерируются случайным образом, злоумышленнику практически невозможно взломать сеанс пользователя.
Если токен сеанса пользователя каким-либо образом скомпрометирован, его нельзя будет использовать после истечения срока его действия. Вот почему время истечения ограничено небольшими интервалами (от нескольких секунд до пары минут).

Поскольку срок действия токена сеанса остается небольшим, нам необходимо часто выпускать новый токен, чтобы пользователь оставался в системе.

Конечно, нельзя ожидать, что пользователь будет входить в систему каждый раз, когда истечет срок действия его токена. Чтобы решить эту проблему, можно создать другой маршрут, который принимает текущий токен сеанса пользователя и выдает новый токен сеанса с обновленным сроком действия.

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

Jhnvlglmlbrt/server-side-session-auth

Создание Server side session аутентификации с сохранением токена в куки клиента

Структура приложения