Маркеры OAuth и сессии в REST
Это достаточно плохо, что Вы должны быть взволнованы даже об отражении, сделанном внутренне библиотеками.NET для критического по отношению к производительности кода.
следующий пример является устаревшим - верный в то время (2008), но давно зафиксированный в более свежих версиях CLR. Отражение в целом является все еще несколько дорогостоящей вещью, хотя!
Рассматриваемый вопрос: Вы никогда не должны использовать участника, объявленного в качестве "Объекта" в блокировке (C#) / оператор SyncLock (VB.NET) в высокоэффективном коде. Почему? Поскольку CLR не может соединить тип значения, что означает, что он должен сделать отражательную проверку типа во время выполнения, чтобы видеть, является ли Ваш Объект на самом деле типом значения вместо ссылочного типа.
2 ответа
Токены OAuth явным образом являются идентификатором сеанса, взаимодействие между запросами в протоколе согласования токенов OAuth не осуществляется без сохранения состояния, поскольку запросы должны выполняться в определенной последовательности, и они требуют хранения для каждого клиента на сервер, так как вам нужно отслеживать вещи, например, когда они были выпущены. Итак, да, OAuth нарушает строгие принципы архитектуры RESTful.
К сожалению, есть Real World TM , с которым нужно бороться, когда нам нужно делать такие вещи, как разрешение приложениям аутентифицироваться от имени отдельных лиц без запроса их пароль, который OAuth делает довольно хорошо. Без такого состояния было бы невозможно реализовать такую же безопасную схему аутентификации. Действительно, одно из изменений, требуемых OAuth (1. 0a) должен был добавить еще состояние в протокол согласования токенов, чтобы снизить риск безопасности.
Итак, подрывает ли он принцип без сохранения состояния в REST? Да. Это имеет значение? Если только вы не живете в башне из слоновой кости: -)
Аутентификация - это состояние, которое необходимо каким-то образом отслеживать при взаимодействии через Интернет. В конечном итоге, если ваше приложение находится в состоянии покоя или нет, сервер должен иметь возможность отслеживать «состояние аутентификации» каждого пользователя. и, к сожалению, это требует некоторого обхода основной природы HTTP без сохранения состояния и любых дополнительных транспортов / методов (например, REST) поверх него.
Следовательно, для разработки любого типа аутентифицированного приложения необходимо где-то заложить принцип состояния, и если это так, OAuth поверх REST, так оно и должно быть!