Как организовать авторизацию в REST API?

Question

[Klein Maximus]

Всем привет.
Примерная архитектура такая:
1) REST API сервис
2) Сайт публичный - доступ имеют все, есть персональный раздел с доступом только для конкретного пользователя
3) Админка - доступ имеют только админы, но права у них могут быть разными
4) Мобильное приложение - функции персонального раздела на сайте.

Почитал вот тут - Как лучше организовать доступ к REST API - понимания не прибавилось.

Посоветуйте, пожалуйста, как правильно и однообразно (чтобы на сайте и в приложениях процесс был одним) осуществить авторизацию в сервисе API?

Comments

[abcyu]

oAuth2?

[Klein Maximus]

abcyu: я не совсем понимаю, как использовать мобильное приложение с oAuth2 - установок же может быть огромное количество. Всем раздавать ключи? Кроме того, все равно остается вопрос авторизации, поскольку с персонального раздела (и мобильного приложения) пользователи должны получить контент с ограничениями.

[abcyu]

Klein Maximus:
> Всем раздавать ключи?
Эту проблему решили, по моему еще в 1970-е годы. Где то в конце их.

[Klein Maximus]

abcyu: Уважаемый, я все же за помощью обратился, а не за стёбом. Если у Вас есть идеи, прошу изложить их более подробно. Если Вам просто нечем заняться и Вы решили меня немножко потроллить, то мне Вас искренне очень жаль :( Приношу извинения, если обидел.

[abcyu]

Klein Maximus: ниже написал

[Klein Maximus]

abcyu: Большое спасибо!

Answer 1

[Петр]

1. Передаете логин/пароль на site.com/login
2. Получаете ID сессии
3. Во всех последующих запросах в header область http запроса добавляете заголовок с ID сессии,
например (authorization: ZGNkOTU3NGZiODkwZTI3OTY1ZmE4M2ExNDllYWQyMTg=)

Comments

[Klein Maximus]

А если злоумышленник узнает этот ID?

[Петр]

Klein Maximus: И что из того? На сервере установите время жизни сессии, далее ошибку доступа и пароль по новой. Для изменения важных данных отправлять логин и пароль в любом случае.

[abcyu]

Все правильно. Только не просто сессия, а токен должен быть, для приложения это удобнее.

[abcyu]

Klein Maximus: На пальцах тут написано network.lamantinclub.com/34-khranyatsya-li-paroli-...

[abcyu]

Klein Maximus: > А если злоумышленник узнает этот ID?
1. Токен должен быть уникальным для различных устройств и браузеров.
2. Каждая защита сообразна уровню предполагаемого взлома. Если Вы параноидальную защиту хотите, то убивайте сессию (токен) на сервере через каждую минуту и новую создавайте только после SMS-подтверждения. Но нужно ли это?

[abcyu]

Klein Maximus: И, как правило, из аккаунта (профиля) на сайте можно удалять все уже активные токены (авторизации приложений) на выбор. Или как минимум все их одним махом.

[Петр]

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

Answer 2

[Никита Гусаков]

jwt.io

Answer 3

[Marcuzy]

Можете попробовать OAuth и не изобретать велосипед, мне понравилось как написано тут https://www.digitalocean.com/community/tutorials/a...