Аутентификация REST API

Question

Аутентификация REST API

148

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

Например, когда пользователь вошел в систему, а затем хочет создать тему форума. Как я узнаю, что пользователь уже зарегистрировался?

Noor 03 нояб. 2011, в 15:32

Источник

3

Вы, вероятно, должны искать «REST-аутентификацию» здесь. Это было рассмотрено во многих других вопросах.
Brian Kelly 03 нояб. 2011, в 20:06
10

В двух словах, пусть клиент отправляет имя пользователя и пароль с каждым запросом, используя HTTP Basic Auth (через SSL!), Или проходит аутентификацию один раз, чтобы у клиента был аутентифицированный сеанс, срок действия которого истечет после некоторого периода бездействия (или если вы решите переопределить его) обработка вашего веб-фреймворка). Затем указанный сеанс может быть сохранен в файле cookie или может быть параметром, передаваемым при каждом запросе (например, JSESSIONID на земле Java).
opyate 14 апр. 2012, в 08:26
0

Смотрите также Как контролировать, кто использует мой веб-виджет .
Arjan 15 дек. 2012, в 00:21
0

@ Копировать с точки зрения безопасности, не очень хорошая идея обрабатывать сеанс с использованием файлов cookie в случае REST API, поскольку злоумышленники могут отправлять запросы без согласия пользователя. Лучше включать хеш или токен сеанса в заголовок HTTP (например, Авторизация).
s3v3n 26 март 2016, в 22:50
1

@ s3v3n Поправь меня, если я ошибаюсь, но и твои, и мои предложения - это просто разные способы использования комбинации заголовок + локальное хранилище для достижения одного и того же результата. Это Authorization заголовок + например , браузер LocalStorage VS Cookie заголовок + стандартный браузер для хранения печенья.
opyate 01 апр. 2016, в 10:55
0

Это зависит от того, в каком домене хранится cookie. Если API отправляет Set-Cookie и он сохраняется в домене API, я вижу в этом потенциальную уязвимость, поскольку любой запрос будет аутентифицирован (даже вредоносный). Если приложение обслуживается из другого домена (статический веб-сайт, CDN и т. Д.) И в этом домене установлены файлы cookie - все должно быть в порядке.
s3v3n 02 апр. 2016, в 14:41
0

Моя рекомендация для тех, кто просматривает этот пост - не катайтесь самостоятельно - используйте то, что уже есть
BKSpurgeon 06 фев. 2018, в 03:18

Показать ещё 5 комментариев

Теги:

rest

api

4 ответа

100

Например, когда пользователь имеет login.Now позволяет сказать, что пользователь хочет создать тему форума, Как я узнаю, что пользователь уже вошел в систему?

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

Проверьте, как Amazon AWS выполняет аутентификацию. Это прекрасный пример "передачи доллара" от одного API к другому.

* Я подумал о добавлении некоторого практического ответа на мой предыдущий ответ. Попробуйте Apache Shiro (или любую библиотеку аутентификации/авторизации). Итог, старайтесь избегать пользовательского кодирования. После того, как вы включили свою любимую библиотеку (я использую Apache Shiro, btw), вы можете сделать следующее:

Создайте API входа/выхода из системы, например: /api/v1/login и api/v1/logout
В этих API входа и выхода из системы выполните проверку подлинности с помощью пользовательский магазин
Результат - это токен (обычно, JSESSIONID), который отправляется обратно клиенту (веб, мобильный, любой)
С этого момента все последующие вызовы, сделанные вашим клиентом будет включать этот токен
Предположим, что ваш следующий вызов выполняется в API под названием /api/v1/findUser
Первое, что должен сделать этот код API, это проверить токен ("is этот пользователь аутентифицирован? ")
Если ответ возвращается как НЕТ, то вы выбрасываете статус HTTP 401 обратно на клиента. Пусть они справятся с этим.
Если ответ "ДА", затем верните запрошенный пользователь

Это все. Надеюсь это поможет.

Kingz 20 нояб. 2013, в 04:29

0

Итак, то, что вы описываете, по сути является сессионным cookie, верно?
LordOfThePigs 29 авг. 2014, в 19:07
0

да, но сеанс "поддерживается" в 2 разных местах. Один на сервере API, другой в браузере. Ответ JSON (или любой другой), возвращаемый браузеру после успешной регистрации, должен сообщать идентификатор сеанса на сервере API обратно браузеру. Эти сеансы независимо управляются их соответствующими агентами.
Kingz 29 авг. 2014, в 19:13
0

@Kingz: Для меня это звучит как сеансовые куки. Для файлов cookie сеанса сервер поддерживает идентификатор сеанса и связывает его с данным пользователем. Затем браузер сохраняет этот идентификатор в файле cookie, который он каждый раз отправляет на сервер. Я не уверен, что вы подразумеваете под "ведением" в 2 разных местах, если только вы не имеете в виду, что токен хранится.
Chris 22 окт. 2014, в 08:31
11

Я полагаю, что Кингз пытался донести идею о том, что механизм ведения сессии намеренно расплывчатый. Сеансовый cookie - только одна из реализаций этого механизма.
justin.hughey 03 нояб. 2014, в 15:01
2

@ Kingz, как насчет безопасности в этом решении, например, если какой-нибудь хакер перехватит ссылку с помощью session_id и начнет отправлять запросы, содержимое которых корректно указывает session_id? Мы можем решить это, добавив SSL к соединению с сервером, но как насчет клиентов?
Ahmad Samilo 25 апр. 2015, в 08:01
0

@Kingz: Так в целом. Если я это реализую. тогда мне нужно использовать куки в качестве токена? По сути, токен, который вы говорите, не что иное, как печенье, верно?
Veer Shrivastav 30 апр. 2015, в 03:35
0

JSESSIONID обычно сохраняется в БД после его создания? Я имею в виду, как сервер узнает, является ли отправленный JSESSIONID правильным?
hytromo 28 июль 2015, в 21:26
0

JSESSIONID является эфемерным и кодируется в cookie и хранится в вашем браузере. На стороне сервера он живет столько же, сколько и сеанс. Потом уходит. Когда он исчезнет, входящий cookie с этим JSESSIONID будет считаться недействительным запросом, и пользователю будет предложено снова войти в систему.
Kingz 05 авг. 2015, в 20:40
1

как предотвратить перехват сеанса в случае «человек посередине»?
m0z4rt 01 окт. 2015, в 10:57
0

Таким образом, любой с токеном является аутентифицированным пользователем. Так что легко взломать сессию и притвориться, что ты законный пользователь.
indianwebdevil 19 апр. 2016, в 04:27
0

@ Kingz, маркер сеанса должен быть отправлен в заголовке запроса или он должен быть частью запроса сына? Так что-то вроде {header:{token:'JJ'},body:{ItemId:5}} . Я предполагаю, что последний потребует, чтобы все было опубликовано, а не получено (это правильное слово, я никогда не думал об этом раньше) . Хранение токена в заголовке обеспечивает чистоту запроса, будь то получение или публикация (или .putting и т. Д.). Я думаю, что ответ может быть простым, мне просто интересно, есть ли стандартная «Лучшая практика» .
JonathanPeel 14 янв. 2017, в 06:58

Показать ещё 9 комментариев

31

Используйте HTTP Basic Auth для проверки подлинности клиентов, но обрабатывайте имя пользователя/пароль только как временный токен сеанса.

Маркер сеанса - это только заголовок, прикрепленный к HTTP-запросу каждый, например: Authorization: Basic Ym9ic2Vzc2lvbjE6czNjcmV0

Строка Ym9ic2Vzc2lvbjE6czNjcmV0 выше - это строка "bobsession1: s3cret" (которая является именем пользователя/паролем), закодированная в Base64.
Чтобы получить маркер временного сеанса выше, укажите функцию API (например: http://mycompany.com/apiv1/login), которая принимает имя мастера-мастера и мастер-пароль в качестве ввода, создает на сервере временное имя пользователя/пароль HTTP Basic Auth и возвращает токен (например: Ym9ic2Vzc2lvbjE6czNjcmV0). Это имя пользователя/пароль должно быть временным, оно должно истечь через 20 минут или около того.
Для дополнительной безопасности убедитесь, что служба REST обслуживается через HTTPS, так что информация не передается открытым текстом

Если вы используете Java, Spring Библиотека безопасности обеспечивает хорошую поддержку для реализации вышеописанного метода

gerrytan 16 май 2014, в 03:59

1

Почему он должен истечь через 20 минут? Что делать, если это веб-сайт, как Facebook, что логин, пока пользователь не выйдет?
Dejell 16 фев. 2015, в 17:22
1

@dejel Я предполагал, что «сессия» носит временный характер. Обычно он истекает, если пользователь бездействует
gerrytan 29 июль 2015, в 08:24
0

Для чего нужна Base64? Вы можете просто вернуть временный пароль. В обоих случаях действительно важно, чтобы этот временный пароль был надежным. Проверьте security.stackexchange.com/a/19686/72945
e18r 14 сен. 2018, в 17:31

Показать ещё 1 комментарий

6

Я думаю, что лучший подход - использовать OAuth2. Google, и вы найдете много полезных сообщений, которые помогут вам настроить его.

Это упростит разработку клиентских приложений для вашего API из веб-приложения или мобильного устройства.

Надеюсь, это поможет вам.

Paulo Henrique 19 нояб. 2012, в 18:11

2

Пожалуйста, прочитайте этот вопрос и ответ Les Hazelwood (автор Apache Shiro).
justin.hughey 03 нояб. 2014, в 15:05

Ещё вопросы

Вы, вероятно, должны искать «REST-аутентификацию» здесь. Это было рассмотрено во многих других вопросах.
В двух словах, пусть клиент отправляет имя пользователя и пароль с каждым запросом, используя HTTP Basic Auth (через SSL!), Или проходит аутентификацию один раз, чтобы у клиента был аутентифицированный сеанс, срок действия которого истечет после некоторого периода бездействия (или если вы решите переопределить его) обработка вашего веб-фреймворка). Затем указанный сеанс может быть сохранен в файле cookie или может быть параметром, передаваемым при каждом запросе (например, JSESSIONID на земле Java).
Смотрите также Как контролировать, кто использует мой веб-виджет .
@ Копировать с точки зрения безопасности, не очень хорошая идея обрабатывать сеанс с использованием файлов cookie в случае REST API, поскольку злоумышленники могут отправлять запросы без согласия пользователя. Лучше включать хеш или токен сеанса в заголовок HTTP (например, Авторизация).
@ s3v3n Поправь меня, если я ошибаюсь, но и твои, и мои предложения - это просто разные способы использования комбинации заголовок + локальное хранилище для достижения одного и того же результата. Это Authorization заголовок + например , браузер LocalStorage VS Cookie заголовок + стандартный браузер для хранения печенья.
Это зависит от того, в каком домене хранится cookie. Если API отправляет Set-Cookie и он сохраняется в домене API, я вижу в этом потенциальную уязвимость, поскольку любой запрос будет аутентифицирован (даже вредоносный). Если приложение обслуживается из другого домена (статический веб-сайт, CDN и т. Д.) И в этом домене установлены файлы cookie - все должно быть в порядке.
Моя рекомендация для тех, кто просматривает этот пост - не катайтесь самостоятельно - используйте то, что уже есть
Итак, то, что вы описываете, по сути является сессионным cookie, верно?
да, но сеанс "поддерживается" в 2 разных местах. Один на сервере API, другой в браузере. Ответ JSON (или любой другой), возвращаемый браузеру после успешной регистрации, должен сообщать идентификатор сеанса на сервере API обратно браузеру. Эти сеансы независимо управляются их соответствующими агентами.
@Kingz: Для меня это звучит как сеансовые куки. Для файлов cookie сеанса сервер поддерживает идентификатор сеанса и связывает его с данным пользователем. Затем браузер сохраняет этот идентификатор в файле cookie, который он каждый раз отправляет на сервер. Я не уверен, что вы подразумеваете под "ведением" в 2 разных местах, если только вы не имеете в виду, что токен хранится.
Я полагаю, что Кингз пытался донести идею о том, что механизм ведения сессии намеренно расплывчатый. Сеансовый cookie - только одна из реализаций этого механизма.
@ Kingz, как насчет безопасности в этом решении, например, если какой-нибудь хакер перехватит ссылку с помощью session_id и начнет отправлять запросы, содержимое которых корректно указывает session_id? Мы можем решить это, добавив SSL к соединению с сервером, но как насчет клиентов?
@Kingz: Так в целом. Если я это реализую. тогда мне нужно использовать куки в качестве токена? По сути, токен, который вы говорите, не что иное, как печенье, верно?
JSESSIONID обычно сохраняется в БД после его создания? Я имею в виду, как сервер узнает, является ли отправленный JSESSIONID правильным?
JSESSIONID является эфемерным и кодируется в cookie и хранится в вашем браузере. На стороне сервера он живет столько же, сколько и сеанс. Потом уходит. Когда он исчезнет, входящий cookie с этим JSESSIONID будет считаться недействительным запросом, и пользователю будет предложено снова войти в систему.
как предотвратить перехват сеанса в случае «человек посередине»?
Таким образом, любой с токеном является аутентифицированным пользователем. Так что легко взломать сессию и притвориться, что ты законный пользователь.
@ Kingz, маркер сеанса должен быть отправлен в заголовке запроса или он должен быть частью запроса сына? Так что-то вроде {header:{token:'JJ'},body:{ItemId:5}} . Я предполагаю, что последний потребует, чтобы все было опубликовано, а не получено (это правильное слово, я никогда не думал об этом раньше) . Хранение токена в заголовке обеспечивает чистоту запроса, будь то получение или публикация (или .putting и т. Д.). Я думаю, что ответ может быть простым, мне просто интересно, есть ли стандартная «Лучшая практика» .
Почему он должен истечь через 20 минут? Что делать, если это веб-сайт, как Facebook, что логин, пока пользователь не выйдет?
@dejel Я предполагал, что «сессия» носит временный характер. Обычно он истекает, если пользователь бездействует
Для чего нужна Base64? Вы можете просто вернуть временный пароль. В обоих случаях действительно важно, чтобы этот временный пароль был надежным. Проверьте security.stackexchange.com/a/19686/72945
Пожалуйста, прочитайте этот вопрос и ответ Les Hazelwood (автор Apache Shiro).

ankitjaininfo · Accepted Answer · 2012-11-19T19-01-00.000Z

Вы можете использовать базовую аутентификацию HTTP. Вы можете безопасно аутентифицировать пользователей, использующих SSL, но немного замедляет работу API.

OAuth - лучшее, что может получить. Обратитесь к инструкции о том, как реализовать:

Рабочая ссылка из комментария: https://www.ida.liu.se/~TDP024/labs/hmacarticle.pdf

Пожалуйста, прочитайте этот вопрос и ответ, предоставленный Les Hazelwood (автор Apache Shiro).
рабочая ссылка: ida.liu.se/~TDP024/labs/hmacarticle.pdf
Полезная ссылка, как Twitter защищает свой REST API: Twitter REST API Security
Поскольку это общепринятый ответ, я считаю важным упомянуть, что вы также можете использовать дайджест-аутентификацию. Узнайте о различиях между базовой и дайджест-аутентификациями здесь: stackoverflow.com/questions/9534602/…