Publi c REST API, дифференцирующий авторизованный и не авторизованный

Question

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

Я понимаю как должны быть построены защищенные API-интерфейсы и какие коды состояния должны быть туда возвращены.

Однако я не уверен, следует ли мне отправлять клиентам publi c apis информацию о том, что пользователь не вошел в систему? И если да, то каков правильный способ отправить эту информацию о том, что api доступен для всех, но пользователь не вошел в систему, а пользователь вошел в систему?

Я использую доступ и refre sh токен на основе механизма аутентификации для защиты моего API. Я могу придумать два способа, но не уверен, какой из них лучше:

1. В случае, если токен доступа передается в publi c api, я проверяю токен как частный api и вернуть 401, если он недействителен, и 200, если он действителен. Затем клиент пытается сгенерировать токен доступа fre sh, который в случае выхода пользователя из системы терпит неудачу. Теперь клиент пытается вызвать api без токена доступа, и, поскольку api - publi c, выполняется logi c и возвращается ответ. При таком подходе клиент понимает, что он вышел из системы, поскольку у него нет действующего токена доступа. Однако есть дополнительные вызовы, которые должны выполняться каждый раз, когда токен доступа больше не действителен (что может происходить много, поскольку токен доступа недолговечный)

2. Если токен недействителен, Я все еще выполняю код и возвращаю результат, но каким-то образом сообщаю клиенту, что токен доступа больше не действителен. В этом подходе нет дополнительных сетевых вызовов, и если клиент может понять ответ при стандартном подходе, он также может знать, что токен доступа больше не действителен. Однако в этом случае, поскольку токен больше не действителен, я не могу предположить, что пользователь вошел в систему и выполняет персонализацию.

Какой подход является лучшим и какова рекомендуемая практика? Или есть какой-либо другой подход, который мне полностью не хватает.

Любая помощь будет принята с благодарностью.

Answer 1

У ваших publi c API должно быть 2 варианта: персонализированный и неперсонализированный. Позвольте клиентскому программному обеспечению решить, нужна ли ему персонализация.

Это не обязательно означает наличие 2 конечных точек для каждого вызова, вы можете добавить параметр запроса ?personalized=true. Важной частью является то, что решение остается за клиентом: клиент должен знать, вошел он в систему или нет, и клиент должен запросить персонализированный ответ (и добавить свой токен доступа).

Это означает, что вы не возвращаете 401 Unauthorized из publi c вызывается неперсонализированный вариант API, но во всех остальных случаях вы возвращаете 401, если действительный токен не был предоставлен.

---

Есть несколько причин для поместите решение в клиент:

Во-первых, сложность клиента: вы не хотите использовать API в предположении, что клиент хочет персонализированный контент только потому, что он вошел в систему. Так как это publi c API, вы не тот человек, который пишет клиента, и вы не знаете, как люди пишут своих клиентов. Во-первых, они могут реализовать токен доступа в каком-то центральном месте, которое всегда отправляет его, если он доступен. Они могут автоматически обновлять токен в потоке, отличном от фактических вызовов API (это будет проблемой для вашего подхода 1). С другой стороны, в большинстве случаев проверка кодов ошибок проще, чем проверка других вещей (что будет проблемой при вашем подходе 2).

Во-вторых, сложность сервера: в какой-то момент зарегистрированный клиент захочет не персонализировать содержание. Это может быть легко или сложно реализовать, в зависимости от того, какая часть вашего серверного кода делает это предположение.

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

---

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

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

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