Скользящий срок действия токена на предъявителя OAuth

Предположим, что мы используем токены носителя OAuth для защиты нашего API. Существует пакет NuGet с промежуточным ПО OWIN, который сделает это за нас: https://www.nuget.org/packages/Microsoft.Owin.Security.OAuth.

Everethig выглядит великолепно, пока не возникнет вопрос о истечении срока действия токена доступа - мы не хотим заставлять пользователя повторно входить в систему снова и снова. Насколько я понимаю, есть три основных способа:

  1. Сделайте время истечения срока действия токена доступа очень большим (например, 1 месяц)
  2. Используйте токены обновления OAuth, которые значительно усложняют как сервер аутентификации, так и код пользовательского приложения (описано в следующей статье http://bitoftech.net/2014/07/16/enable-oauth-refresh-tokens-angularjs-app-using-asp-net-web-api-2-owin/)

Мне любопытно, можно ли создать конечную точку, для которой потребуется токен доступа, срок действия которого истекает, и просто ответить новым токеном доступа, чтобы имитировать скользящее истечение срока действия для токенов доступа OAuth?


person Eugene D. Gubenkov    schedule 07.04.2015    source источник
comment
Звучит выполнимо. Я никогда не делал этого один, но не вижу никаких потенциальных проблем. Я даже не думаю, что имеет значение, разделены ли сервер ресурсов и сервер авторизации или нет, поскольку RS может незаметно вызывать AS в фоновом режиме. И ваш API просто вернет новый токен в заголовке. Клиент просто должен знать, что токен может быть заменен другим токеном.   -  person Wiktor Zychla    schedule 07.04.2015


Ответы (1)


ПРЕДУПРЕЖДЕНИЕ! Вот решение, которое НИКОМУ НЕ ДОЛЖНО ИСПОЛЬЗОВАТЬ, если вы не на 100% уверены, что ваше приложение гарантирует (что невозможно), что токен доступа не может быть скомпилирован ( например, уязвимость XSS позволяет украсть токен доступа). В этом решении после утечки токена доступа его можно использовать для бессрочного продления доступа. Токены обновления OAuth решают именно эту проблему, ограничивая доступ в случае компрометации токена доступа очень коротким промежутком времени, обычно около 15 минут.

[Authorize]
public class RefreshTokenController : ApiController
{
    [HttpGet]
    public HttpResponseMessage ReissueToken()
    {
        // just use old identity
        var identity = ((ClaimsPrincipal)User).Identity as ClaimsIdentity;

        var ticket = new AuthenticationTicket(identity, new AuthenticationProperties());
        DateTimeOffset currentUtc = new SystemClock().UtcNow;

        ticket.Properties.IssuedUtc = currentUtc;
        ticket.Properties.ExpiresUtc = currentUtc.AddMinutes(30);

        string token = Startup.OAuthBearerAuthOptions.AccessTokenFormat.Protect(ticket);

        return new HttpResponseMessage(HttpStatusCode.OK)
        {
            Content = new ObjectContent<object>(new
            {
                accessToken = token,
                expiresIn = (int)((ticket.Properties.ExpiresUtc.Value - ticket.Properties.IssuedUtc.Value).TotalSeconds),
            }, Configuration.Formatters.JsonFormatter)
        };
    }
}
person Eugene D. Gubenkov    schedule 09.04.2015
comment
Если злоумышленник завладел токеном доступа, это позволило бы ему поддерживать доступ на неопределенный срок, постоянно перевыпуская скомпрометированный токен доступа. Это проблема, которую пытаются решить токены обновления. Если вы выберете этот маршрут, обязательно сохраните токены доступа в базе данных и добавьте необходимые проверки кода, чтобы их можно было отозвать в случае компрометации. - person Taylor Buchanan; 07.05.2015
comment
@TaylorBuchanan, точно, спасибо! Я обновлю ответ, чтобы предупредить читателей. - person Eugene D. Gubenkov; 08.05.2015
comment
Поскольку токен обновления также хранится на стороне клиента, как токен доступа, в случае кражи токена обновления его можно использовать до тех пор, пока администратор не отменит его. В итоге мы получаем ту же ситуацию, что и с токеном доступа? я что-то упускаю? Пожалуйста помоги. - person Beryl Wilson; 16.01.2016
comment
@BerylWilson, вот почему в спецификации различаются публичные и конфиденциальные клиенты (rfc6749, раздел 2.1). Согласно разделу 10.4 rfc6749, токены обновления должны выдаваться только конфиденциальным клиентам (веб-приложение или собственное приложение), которые способны поддерживать конфиденциальность своих учетных данных (например, клиент, реализованный на защищенном сервере с ограниченным доступом к учетным данным клиента), или возможность безопасной аутентификации клиента с помощью других средств. Например. веб-приложение + файл cookie только для HTTP затрудняет компрометацию токена обновления (сам Клиент не имеет доступа к нему из JS). - person Eugene D. Gubenkov; 17.01.2016
comment
@BerylWilson, я имею в виду, что если ваш клиент - это просто приложение JS (общедоступный клиент), вам вообще не разрешено по спецификации OAuth использовать токены обновления. - person Eugene D. Gubenkov; 17.01.2016
comment
@ EugeneD.Gubenkov Спасибо за ответ. - person Beryl Wilson; 09.02.2016