Какой HTTP статус использовать?

Question

[Евгений]

Имеем некое RESTful API.

Клиент проходит аутентификацию и получает токен.
Далее для доступа к определённым страницам клиент должен предоставить этот токен.

Какой HTTP статус должен вернуть сервер если токен не передан?
— 400 Bad Request (так как токен является обязательным параметром)
— 401 Unauthorized
— 403 Forbidden

А если передан неверный токен?

UPD
… или истекла сессия для переданного токена?

UPD 2
Согласно "Диаграмме принятия веб-сервером решений на основе заголовков" из википедии, происходит следующее:


Можно ли расценивать отсутствие параметра как «Bad Request»?

The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.

RFC 2616 пункт 10.4.1

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

Далее сервер проверяет авторизован ли клиент.
Если токен неверен или отсутствует (допустим мы решили код 400 не использовать), то сервер отдаёт код 401 — просит пройти авторизацию.

Наконец, сервер узнал пользователя. Есть доступ — работаем дальше, нет доступа — 403 статус.

Кроме того в RFC 2616 сказано о статусе 403:

The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated.

Другими словами:
400 или 401 если токен не передан
401 если токен неверен / истекла сессия
403 токен передан и клиент узнан, но не имеет доступа к контенту

Прав ли я?

Answer 1

[karazyabko]

403 для обеих ситуаций, если идет разграничение прав, если просто проверка идентификации — 401

Comments

[Евгений]

Тут речь скорее о проверке идентификации.
А какой ответ был бы ожидаем для клиента во втором случае, когда например истекла сессия для переданного токена?

[karazyabko]

По моему скромному мнению, если токен просрочен, это все равно, что его нет, так что для доступа к контенту 403 — ваше все. К тому же исходя из вашего условия «Далее для доступа к определённым страницам клиент должен предоставить этот токен», то есть на некоторые страницы видимо он может и без токена зайти, это и есть пресловутое разграничение прав доступа, а это снова 403

[Евгений]

Ну страница аутентификации (где клиент должен получить токен) в любом случае открыта и не требует токена. Разграничение прав — это когда к определённой странице есть доступ не у каждого аутентифицированного клиента.
Т. е., мне кажется, 403 код как будто бы говорит: «Привет! Я тебя знаю. Но для тебя этот контент закрыт.»

Answer 2

[barker]

А это принципиально или просто хочется сделать как можно более «правильно»?)
Я бы выбрал 403 и для если не передан и для неверного. Если действительно параметр требуемый на уровне API, то для отсутствующего можно и 400, но это спорный вопрос. А 401 всё же для другого задуман.

Comments

[Евгений]

Делать правильно априори принципиально. Какой смысл во всех этих статусах если их использовать не по назначению?

Answer 3

[karenishe]

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

Comments

[Евгений]

API при любом раскладе в ответе выдаст сообщение об ошибке вроде «Token is required» или «Token is invalid»

[karenishe]

Тогда возникает вопрос, зачем вообще задумываться о коде ошибки?:) Хорошо бы, чтобы текст ответа соответствовал коду и сути дела.

Answer 4

[Андрей Нехайчик]

Для запроса аунтификации:
* 400 если токен вообще не был передан
* 401 если неверный

Для остальных страниц:
* 403 если токен вообще не был передан
* 403 если неверный

Comments

[Mikhail Osher]

Это именно то, что крутилось у меня в голове.

[Евгений]

Я обновил вопрос, прокомментируйте пожалуйста

Answer 5

[dustalov]

401 — не передан, 403 — некорректен.

Comments

[Евгений]

А какой заголовок WWW-Authenticate передавать при 401 статусе?

Answer 6

[Mikhail Osher]

Неправильный токен — доступ закрыт.

HTTP/1.1 403 Forbidden?