Ответ 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 с минимальным минимумом.. Это защитит токен в транспорте.
Если вы защищаете что-то чрезвычайно чувствительное, вы должны сохранить срок действия токена в очень короткое время. Если вы защищаете что-то менее чувствительное, вы можете продлить срок службы. Чем дольше токен, если он действителен, тем больше будет время, которое злоумышленник должен будет олицетворять аутентифицированного пользователя, если пользовательская машина скомпрометирована.