Ситуация такая. Поставили задачу написать backend с которым будут работать несколько клиентов с разным фронтом. backend будет на отдельном сервере, и по сути является API. Клиенты будут локальными javascript интерфейсами.
Первая сложность с которой столкнулся, это нужно обезопасить API от ботов. То есть к примеру на регистрацию добавить капчу. Но как работать с капчей и API, которые отдаются через ajax?
Вторая сложность это CRSF и iFrame. Допустим у пользователя на компьютере есть два frontend клиента. Каждый и которых просто js файл. Первый написал я, а второй от третьих лиц. И так как домен у них один 127.0.0.1, то они будут иметь общий localStorage и отправлять данные от имени друг друга если куки вернутся.
Роман Усенко: Спасибо помечается ответом =)
В токене генерируете права доступа, данные пользователя и др. нужную вам информацию.
Далее всем этим пользуетесь.
В случае с Cookie им выставлялся флаг HttpOnly и их нельзя было получить с помощью Javascript проведя успешную XSS. А токен можно увести получается. Как вариант привязывать его к IP, но думаю нужно искать какие-то решения
Роман Усенко: Можно и логин с паролем увести =)
Готового решения не могу предоставить, т.к. слишком обширный код реализации.
Использую Symfony3 + https://github.com/lcobucci/jwt
Если API-backend будет на PHP, да, то рекомендую вот такую реализацию OAuth2 https://oauth2.thephpleague.com/ , кстати, там есть и валидатор токенов для сервера ресурсов. (Не очень вчитывался в предидущее написаное, так-что заранее извиняюсь.)
Марат Максумов: Помимо того что ApiDoc даст вам платформу для тестирования вашего API, он так же имеет полезные аннотации в виде: тип запроса, версия, права доступа и еще много чего полезного.
Пока что полет нормальный. Но есть несколько вопроса по формату. С остальными полями вроде разобрался. А вот:
1. aud - это страница назначения, то что ожидаем получить в HTTP_REFERER после получения ответа от клиента?
2. iss - имя сервера/приложения. Это для масштабирования?
3. sub, prn - тут вообще белое пятно
4. jti - где может быть использован, и что обеспечивает его уникальность?
Вы не указали, для каких целей пишете API, а от этого многое зависит.
API используется как правило, для взаимодействия сервер-сервер. И тогда у вас нет view уровня.
Капча это view уровень, он не должен иметь отношения к API сервису.
При таком взаимодействии сразу исчезают проблемы с CRSF и iFrame.
Проще простого:
1. Регистрация выполняется через капчу
2. Ключ приходит через SMS или E-MAIL
3. При запросах - используется hash-подпись для проверки на стороне сервера.
Подробнее - здесь.
Ограничить на сервере количество запросов в час/минуту, особо рьяным отправлять капчу. Все. Вы никогда не узнаете, исполняется на клиенте запрос от живого человека или от бота. csrf, jwt - это не та песня, они созданы, чтобы защитить клиента от постороннего вмешательства, но если клиент сам решит написать бота, вы никак не сможете этому препятствовать.
Нужно знать кто является клиентом, много ли их. Может быть им проще выдать секретные ключи и подписывать запрос токеном с использованием секрета.
А от ботов защититься будет сложно. Как верно указали выше, ограничить кол-во запросов с одним токеном.
Средний
