[Moscow.pm] Аутентификация для REST API

[Иван Соколов]

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

Всякие OAuth хороши, когда надо от юзера получить разрешение.


22 сентября 2016 г., 17:12 пользователь Aliaksandr Zahatski <
zahatski на gmail.com> написал:

> Всем привет!
>
> Может подойти простой вариант c HTTP Basic Auth:
>
> curl -u "username:remotekey" -d "body=Hello+World" \
>      http://example.com/v1/entry
>
> где remotekey - отдельная сущность в настройках пользователя или
> эквивалентно паролю
>
> С уважением,
> Александр
>
>
> 22 сентября 2016 г., 14:35 пользователь Victor Efimov
> <victor на vsespb.ru> написал:
> > ну если по-хорошему делать то симметричаня подпись запроса, например.
> > например как тут
> > http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html#
> ConstructingTheAuthenticationHeader
> >
> > 22 сентября 2016 г., 6:17 пользователь Anatoly Y <iskhartakh на gmail.com>
> написал:
> >> Привет.
> >> Если третьим лицам ничего делегировать не нужно. Используй подписанные
> куки,
> >> это надёжный, простой и удобный механизм.
> >>
> >> 2016-09-21 21:53 GMT+07:00 Alexey Shrub <worldmind на mail.ru>:
> >>>
> >>> Всем привет,
> >>>
> >>> вопрос не столько про перл, но думаю допустимый, нужно мне сделать REST
> >>> сервис (кстати думаю попробовать
> >>> https://metacpan.org/pod/Mojolicious::Plugin::OpenAPI) и что-то у
> меня нет
> >>> ощущения уверенности в вопросе аутентификации.
> >>> API должно быть универсальным, а значит с ним должно быть удобно
> работать
> >>> и с мобильных устройств (из приложений), и из браузера (джаваскриптом)
> и с
> >>> серверов клиентов, тестирование curl'ом тоже должно быть удобным.
> >>> Прочитал несколько статей, но сильно яснее не стало, пока кажется что
> >>> обычные клиентские куки (подписанные или зашифрованные, полученные в
> обмен
> >>> на имя юзера и хешированный пароль) это оптимальный вариант.
> >>> Однако во всяких статьях часто упоминают про OAuth, пока не пойму
> будет ли
> >>> с него польза если нет необходимости показывать данные третьим лицам.
> Вроде
> >>> в OAuth 2 есть функционал аналогичный кукам, но имеет ли смысл
> непонятно, да
> >>> и неясно что в перле с поддержкой серверного OAuth 2, вроде есть
> >>> https://metacpan.org/pod/OAuth::Lite2 но какой в нём уровень
> поддержки не
> >>> написано, может кто юзал?
> >>>
> >>> Другие варианты мне кажутся менее подходящими:
> >>> - Digest authentication - знаю что она более правильная чем Basic
> auth, но
> >>> не юзал, как понимаю она, как и basic auth, реализуется на уровне
> >>> веб-сервера, что делает менее удобным управление юзерами - надо из
> базы в
> >>> какой-то файлик переносить
> >>> - клиентские сертификаты это круто, но немного сложно для клиентов
> >>>
> >>> Может у кого есть опыт в этом вопросе, основанные на этом опыте
> убеждения
> >>> и готовность ими поделится?
> >>>
> >>>
> >>> --
> >>> Moscow.pm mailing list
> >>> moscow-pm на pm.org | http://moscow.pm.org
> >>
> >>
> >>
> >> --
> >> Moscow.pm mailing list
> >> moscow-pm на pm.org | http://moscow.pm.org
> >>
> > --
> > Moscow.pm mailing list
> > moscow-pm на pm.org | http://moscow.pm.org
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
С уважением,
Иван
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20160922/eebbe790/attachment-0001.html>