Как заставить истечение токена доступа OAuth2 с помощью DotNetOpenAuth

Question

Я реализую сервер авторизации/ресурсов OAuth2 на основе DotNetOpenAuth. Мой сервер будет выпускать токены доступа с очень долгим сроком службы. Эти жетоны будут использоваться с устройств iOS. Поток, как я вижу, выглядит следующим образом: 1) пользователю предлагается ввести свое имя пользователя/пароль на устройстве iOS; 2) запрашивается токен доступа с типом предоставления типа учетных данных пароля владельца ресурса; 3) токен предоставляется и сохраняется на устройстве iOS для будущего использования.

Теперь время от времени пользователи становятся инвалидами. Я хотел бы одновременно аннулировать токен. Как мне это сделать? I подозреваемый, что мне нужно использовать метод ICryptoKeyStore.RemoveKey, но не уверен, как найти, какой ключ удалить.

Примечание 1: в будущем сервер будет использоваться сторонними веб-приложениями.

Примечание 2: требование о предоставлении типа гранта учетных записей владельца ресурса основывается на том факте, что было решено, что реализация переадресации браузера на устройстве iOS не стоит времени.

Update 1 Некоторые раскопки в исходном коде позволяет предположить, что DotNetOpenAuth не поддерживает эту возможность, чтобы заставить истечение срока действия маркеров из коробки. Более того, в стандартном времени реализации токена даже не проверяется. Насколько я вижу, calss отвечает за это StandardAccessTokenAnalyzer и игнорирует свойства Lifetime и UtcCreationDate. Также не кажется, что стандартный класс ResourceServer имеет любой кодированный доступ к базе данных, действительность маркера проверяется только содержимым токена, поэтому кажется, что если мне нужно добавить способность истекать токенов, мне нужно подключить ResourseServer к базе данных самостоятельно , Я что-то упускаю?

Update 2 Я думаю, что я нашел ответ здесь: https://groups.google.com/forum/#!topic/dotnetopenid/aLabu1ujkt4 Это не то, что я надеялся, и я до сих пор есть несколько unclarities. Например, Андрей написал:

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

Неясно как эта проверка может случиться, учитывая, что AccessToken не включает Authorization Id. Это может затруднить поиск целевой записи авторизации. Теоретически мы можем попытаться найти это с помощью комбинации времени клиента, пользователя и времени, но, насколько я вижу, нет никакой гарантии, что они будут уникальными.

Answer 1

Теперь время от времени пользователи становятся инвалидами. Я хотел бы одновременно аннулировать токен. Как мне это сделать? Я подозреваю, что для этого мне нужно использовать метод ICryptoKeyStore.RemoveKey, но не знаю, как найти, какой ключ удалить.

Вы отменяете токены, отменяя авторизацию за токеном. Обычно это означает, что вы удаляете запись в таблице авторизации вашей базы данных. Эффект, который должен иметь это, заключается в том, что ваша реализация IAuthorizationServerHost.IsAuthorizationValid вернет false для этой авторизации.

Это не сразу отменяет токены доступа, но блокирует клиенту от обновления токенов доступа с истекшим сроком действия.Таким образом, до тех пор, пока ваши токены доступа имеют достаточно короткий срок службы (час или меньше), тогда отключенная учетная запись пользователя означает, что весь клиентский доступ завершится в течение часа.

Примечание 2: требование о предоставлении типа гранта учетных записей владельца ресурса основывается на том факте, что было решено, что реализация переадресации браузера на устройстве iOS не стоит времени.

Это ваше приложение. Но я призываю всех использовать правильный поток перенаправления браузера. Вероятно, пользователь уже зарегистрировался на вашем сервере в браузере устройства, поэтому они могут вообще не вводить свои учетные данные, улучшая ваши коэффициенты конверсии. Пользователи также с большей вероятностью доверяют браузеру запрашивать свои учетные данные, чем приложение устройства. По крайней мере, я надеюсь.

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

Update 1 Некоторые раскопки в исходном коде позволяют предположить, что DotNetOpenAuth не поддерживает эту возможность, чтобы заставить истечения срока действия маркера из коробки. Более того, в стандартной реализации время жизни токена даже не проверяется. Насколько я вижу, calss несет ответственность за это StandardAccessTokenAnalyzer и игнорирует свойства Lifetime и UtcCreationDate.

DotNetOpenAuth делает чек и отклонять с истекшим сроком действия токенов. Это просто не в этом классе. Он проверяется в коде, который десериализует токены доступа.

Также не кажется, что стандартный класс ResourceServer имеет какой-либо доступ к базе данных закодирован, маркер валидность проверяет лексемы содержания только, так что кажется, что если мне нужно добавить возможность истекает маркеры мне нужно проволока сам ResourseServer в базу данных. Я что-то упускаю?

Вы правильно, что ResourceServer класс не требует доступа к базе данных, поскольку маркеры доступа считаются действительными в течение всей своей жизни (они не-revokable по умолчанию). Вот почему рекомендуются короткие сроки доступа к токенам. Это не так далеко, как вы думаете. Например, проверка подлинности форм ASP.NET, которую вы, скорее всего, используете уже, основана на том же шаблоне: один раз удостоверьтесь, пользователь попал в базу данных для проверки учетных данных, а затем выдал зашифрованный и подписанный HTTP-файл cookie агенту пользователя. С этого момента база данных не попадает на каждый входящий HTTP-запрос - подпись cookie проверяется, а затем считается действительной до истечения срока действия файла cookie. Тот же принцип. За исключением того, что в файле cookie HTTP есть , скользящий тайм-аут, так что до тех пор, пока пользователь остается активным на сайте, им не нужно повторно проверять подлинность. С помощью токенов доступа OAuth 2 они истекают независимо от того, насколько активно они используются, заставляя обновление токена, которое затем может быть отклонено для блокировки доступа.

Непонятно, как эта проверка может произойти, учитывая, что AccessToken не включает идентификатор авторизации. Это может затруднить поиск целевой записи авторизации. Теоретически мы можем попытаться найти это с помощью комбинации времени клиента, пользователя и времени, но, насколько я вижу, нет никакой гарантии, что они будут уникальными.

Это правда нет ID не включен, но кортеж клиента пользовательского IssueDate-рамок должен быть уникальным, так как ваша таблица авторизации должна иметь уникальное ограничение на это, так как имея дубликаты не будут иметь смысл. Кроме того, если они не были уникальными, просто наличие любой записи с этим кортежем предполагает, что авторизация действительно.

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