Как сделать аутентификацию в современном веб-приложении?

Question

[Павел]

Если у веб-приложения предполагается следующая архитектура:
Backend: api написанное на Go.
Клиент: Статические страницы с JavaScript, которые обращаются к API бэкэнда.

Как в таких приложениях принято делать аутентификацию?
Как делать первичную аутентификацию?
Правильно ли я понимаю, что при каждом обращении к API на бэкэнде надо проверять аутентифицирован пользователь или нет. Как это следует делать?

Comments

[abcyu]

Если сервер отдает открытые данные, то аутентификация не нужна.

Answer 1

[nirvimel]

Как и везде:

1. /api/auth принимает {"login":"user", "password":"qwerty"} возвращает {"session_id":"UUID:4545633896344"}
   
2. Все остальные API принимают параметр session_id, без него отвечают 401, с неверным session_id отвечают 403.
   
3. Сессии не вечные, через N минут после последнего api-вызова стираются.
   
4. Если клиент внезапно получает 403, то не кричит об этом юзеру сразу, а пытается перелогиниться хотя бы один раз.
   

Comments

[Lander]

Небольшое дополнение: на шаге один очень желательно использование https, чтобы избежать перехвата.

[Павел]

Где хранить токен на стороне клиента?

[nirvimel]

Павел: В обычной переменной. Что мешает?

[Павел]

nirvimel: впринципе ничего. А если происходит редирект на другую статическую страницу, как туда передать этот токен?

[nirvimel]

Павел: Веб-приложение - это обычно одностраничник в котором все происходит на клиенте без редиректов.
Многостраничный сайт - совсем другие технологии, страницы там генерируются из шаблонов на сервере, можно обойтись без api, или api будет в роли чего-то дополнительного. Конечно, там и авторизация совсем другая: на сервере вместе с session_id хранится все "содержимое" сессии, на/с клиента session_id передается через cookies.

[Павел]

nirvimel: а если у меня несколько страниц (а не spa) и я не хочу генерировать страницы на сервере, я могу передавать токен между ними, или при переходе в пределах одного домена придется аутентифицироваться повторно?

[nirvimel]

Павел: Можно хранить токен в cookies. Писать/читать их можно на javascript. Время жизни cookie можно установить равным ограничению времени сессии на сервере.

[Павел]

nirvimel: теперь понятно, спасибо!

[⚡ Kotobotov ⚡]

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

[nirvimel]

дима кубитский: Пожалуйста по-подробнее, а то я что-то упустил. Как происходит аутентификация без сессий? Логин/пароль на каждый запрос пересылается что ли? И в чем тут безопасность?

[⚡ Kotobotov ⚡]

nirvimel: нет логин и пароль не отсылается, отсылаются необходимые данные, о правах пользователя, и что это за пользователь в зашифрованном виде в токене, и каждый сервер просто на основании алгоритма шифрования, дешифрует эти данные, и из них же получает информацию о правах доступа пользователя, что позволяет не запрашивать данные о правах каждый раз в одной BD, это решает проблему горизонтального масштабирования, которая при старой схеме, упирается в производительность авторизационного сервера, и практически не масштабируется.

[v- smerti]

nirvimel: jwt или пример на пальцах в моём ответе ниже

Answer 2

[v- smerti]

делаем метод авторизации. К примеру
/users.Auth/
Который принимает параметры

{
 "login":"",
 "email":"", //необязательно но я использую
 "pass":""
}

И возвращает token

rb := make([]byte, 64)
_, err := rand.Read(rb)
if err != nil {
  log.Print(err)
}

var token string = `{
  "user_id":"",
  "name":"",
    ...,
  "salt": "`+base64.URLEncoding.EncodeToString(rb)+`",
   "expiries":"", //время жизни токена 
}`
encrypt_data := xxtea.Encrypt([]byte(token), []byte("Ваш ключ для шифровки токена"))
return base64.URLEncoding.EncodeToString(encrypt_data)

xxtea https://github.com/xxtea/xxtea-go

Всем остальным методам посылаем ещё токен.
Можно ещё использовать стандартные сессии но тогда нагрузка на сервер большая. А так всё храниться на стороне клиента.

Comments

[Павел]

дима кубитский: так есть же github.com/dgrijalva/jwt-go
Я погуглил и альтернатив ему на сегодня нет.

[Павел]

дима кубитский: Дмитрий, я ведь привел ссылку на самую популярную jwt-библиотеку на гитхабе для Go. github.com/dgrijalva/jwt-go
Вы о ней говорите, что она защитит лишь от школьников?

[⚡ Kotobotov ⚡]

Павел: соль есть, поторопился, по диагонале прочитал)

Answer 3

[Fr0stDev1]

Есть хорошая статья на хабре