2015-01-08 2 views
1

Я установил аутентификацию для веб-API, которая почти идентична этому блогу здесь oauth-refresh-tokens от Taiseer Joudeh.Отменить маркер доступа OAuthBearerAuthentication

Он прекрасно работал, пока я не встретил вопрос:

  • Мы Пользователь А и пользователь В настоящее время вошли в систему.
  • Пользователь A как администратор, удаляет пользователя B из системы.
  • Пользователь B все еще имеет разрешение, чтобы получить доступ к веб-домаркер является истек.

Я провел некоторое исследование, и все они сказали, что аннулирование токена доступа довольно сложно (или невозможно в OAuth). Единственное, что я мог сделать, это установить тайм-аут короче. Это все еще сулит мне в голову, и мне не нравится идея, что токен доступа по-прежнему действителен (хотя и ограниченный).

Итак, есть ли какой-либо лучший подход или какой-либо совет был бы очень признателен.

ответ

0

Благодарим за обращение и использование моего сообщения в блоге, проверьте это answer, так как вам нужно сохранить идентификатор токена доступа в БД, если вы хотите отменить их.

+0

Извините, но я не могу найти информацию о том, что вы упомянули в этой теме. Вы имели в виду отменить «Обновить токен»? –

0

Это возможно, если вы проверяете пользователя на таблицу базы данных каждый запрос. Что-то в строках следующего в global.asax будет работать.

protected void Application_AuthenticateRequest(object sender, EventArgs e) 
    { 
     if (/*check table to see if user is allowed in*/) 
     { 
      HttpContext.Current.User = null; 
     } 
    } 
+0

Я думал об этом. Это могло бы повредить производительность плохо, если я должен запросить базу данных по каждому отправляющему запросу. Кроме того, это приведет к поражению цели аутентификации на предъявителя. –

2

Используйте refresh_token и access_token, как они были разработаны и сократить срок службы маркеров доступа к продолжительности, что является приемлемым для вас и пойти как низко как вам нужно идти. Поскольку вы оба являетесь сервером ресурсов и сервером авторизации, асимптота означает, что вы все равно проверите пользователя на каждом вызове, как это предложено в других ответах, но:

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

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

+0

Кэширование дает мне немного больше контроля. Я могу решить, когда удалять кеш (в основном то же самое с отменой токена доступа). Но, в любом случае, это все еще не очень хороший подход. –

+0

. Если я использую токен обновления, и если у меня установлено время истечения срока доступа до 30 минут, но через 10 минут только , если администратор изменяет роль этого пользователя или удаляет этого пользователя из системы, то в в этом случае я могу удалить запись из токена обновления , чтобы пользователь не смог запросить токен доступа дальше, но все еще осталось 20 минут, и пользователь может получить доступ к защищенному ресурсу. Теперь в случае кеша и базы данных я могу просто удалить этот accesstoken из кеша немедленно в случае пользователь аннулирует доступ. Что вы думаете об этом? –

+0

@HungLe Почему вы думаете, что клей для доступа к кешированию не является хорошим подходом. Можете ли вы рассказать мне об этом, потому что я думаю реализовать механизм кеширования для accesstoken? –

Смежные вопросы