Использование JWT для реализации аутентификации на веб-интерфейсе Asp.net

Я читал о JWT.

Но из того, что я прочитал, это не механизм аутентификации, а скорее как важный компонент механизма аутентификации.

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

Я хочу реализовать его в терминах ASP.NET web api 2, который будет использоваться мобильным приложением.

Итак, шаг 1:

app = > Сервер: Вход (пользователь, пароль)
Сервер = > приложение: Войдите в систему, используйте ваш JWT
app = > server: Получить мой профиль (отправляет JWT с запросом) Затем сервер расшифровывает JWT и определяет запросы Identity.

Теперь это только мое понимание этого, Посмотрите, что я могу быть на совершенно неправильном пути.

Является идеальным из JWT, так что вам не нужно проходить аутентификацию по каждому запросу? Я просто аутентифицирую учетные данные пользователей один раз (при первом входе в систему) и там после того, как сервер может просто использовать JWT и не нужно искать пользователей pw и пользователя в БД?

Я просто хочу использовать JWT для Identity, которым является пользователь. Затем я авторизуюсь после того, как я их аутентифицирую. Как я знаю, существует большая путаница с новыми MVC и аутентификацией и авторизацией.

Итак, к чему относится мой вопрос.

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

Мои требования:

Нужно только проверять db для учетных данных пользователей один раз за сеанс? Из-за использования bcrypt с использованием большого количества ресурсов для сравнения паролей.
Должна быть в состоянии идентифицировать пользователя по их запросу. (I.e, которым они являются, userId будет достаточно), и предпочтительно без доступа к БД также
Должно быть как можно меньше накладных расходов, в отношении ресурсов на стороне сервера, обрабатывающих запрос.
Если злоумышленнику пришлось копировать предыдущий запрос устройства, он не должен иметь доступ к данным реальных пользователей. (Очевидно)

Спасибо

Ответ 1

Ваше понимание JWT - это хорошо. Но вот пара поправок и некоторые рекомендации.

Аутентификация и авторизация

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

Шифрование

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

Претензии

Ваши JWT могут содержать любую требуемую информацию. Имя пользователя, дата рождения, адрес электронной почты и т.д. Вы делаете это с помощью утверждений на основе утверждений. Затем вы просто укажете своему провайдеру, чтобы сделать JWT с этими претензиями из принципа требований. Следующий код из этого примера перезагрузки Членства и показывает, как это делается.

    public override Task GrantResourceOwnerCredentials(OAuthGrantResourceOwnerCredentialsContext context)
    {
        var svc = context.OwinContext.Environment.GetUserAccountService<UserAccount>();
        UserAccount user;
        if (svc.Authenticate("users", context.UserName, context.Password, out user))
        {
            var claims = user.GetAllClaims();


            var id = new System.Security.Claims.ClaimsIdentity(claims, "MembershipReboot");
            context.Validated(id);
        }

        return base.GrantResourceOwnerCredentials(context);
    }

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

Реализация

Очень простой способ внедрения провайдера Token - использовать сервер авторизации Microsoft OAuth в вашем проекте WebAPI. Это дает вам голые кости того, что вам нужно для создания сервера OAuth для вашего API.

Вы также можете заглянуть в Thinktecture Identity Server, который даст вам гораздо более легкий контроль над пользователями. Например, вы можете легко реализовать токены обновления с сервером идентификации, где пользователь аутентифицируется один раз, а затем в течение определенного периода времени (может быть, месяц) они могут продолжать получать короткоживущие JWT с Identity Server. Световые индикаторы хороши, потому что они могут быть отменены, тогда как JWT не могут. Недостатком этого решения является то, что вам нужно настроить другой сервер или два для размещения службы Identity.

Чтобы иметь дело с последним моментом, чтобы злоумышленник не смог копировать последний запрос для доступа к ресурсу, , вы должны использовать SSL с минимальным минимумом.. Это защитит токен в транспорте.

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

Ответ 2

Я написал подробное сообщение в блоге о настройке сервера авторизации OWIN для выдачи подписанных JSON Web Tokens вместо токена по умолчанию. Таким образом, серверы ресурсов (Аудитория) могут зарегистрироваться на сервере авторизации, а затем они могут использовать токены JWT, выпущенные стороной-эмитентом Token, без необходимости унифицировать значения machineKey между всеми сторонами. Вы можете прочитать сообщение JNON Web Token в ASP.NET Web API 2 с помощью Owin