JwtSecurityTokenHandler() ValidateToken проверки() :: Подпись не удалось ... sha256 не поддерживается в этом контексте

Question

Я получаю следующее сообщение об ошибке, когда я выполняю функцию JwtSecurityTokenHandler() ValidateToken():.

Вот мой псевдо-код:

var jwtToken = {...} 
var tokenHandler = new JwtSecurityTokenHandler(); 
var validationParameters = new TokenValidationParameters {...}; 
var claimsPrincipal = tokenHandler.ValidateToken(jwtToken, validationParameters); 

А вот ошибка:

Jwt10316: Signature validation failed. Keys tried: 'System.IdentityModel.Tokens.X509AsymmetricSecurityKey'. 
Exceptions caught: 
'System.InvalidOperationException: Jwt10518: AsymmetricSecurityKey.GetHashAlgorithmForSignature('http://www.w3.org/2001/04/xmldsig-more#hmac-sha256') threw an exception. 
AsymmetricSecurityKey: 'System.IdentityModel.Tokens.X509AsymmetricSecurityKey' 
SignatureAlgorithm: 'http://www.w3.org/2001/04/xmldsig-more#hmac-sha256', check to make sure the SignatureAlgorithm is supported. 
Exception: 'System.NotSupportedException: Crypto algorithm 'http://www.w3.org/2001/04/xmldsig-more#hmac-sha256' not supported in this context. 
    at System.IdentityModel.Tokens.X509AsymmetricSecurityKey.GetHashAlgorithmForSignature(String algorithm) 
    at System.IdentityModel.Tokens.AsymmetricSignatureProvider..ctor(AsymmetricSecurityKey key, String algorithm, Boolean willCreateSignatures)'. 
---> System.NotSupportedException: Crypto algorithm 'http://www.w3.org/2001/04/xmldsig-more#hmac-sha256' not supported in this context. 
    at System.IdentityModel.Tokens.X509AsymmetricSecurityKey.GetHashAlgorithmForSignature(String algorithm) 
    at System.IdentityModel.Tokens.AsymmetricSignatureProvider..ctor(AsymmetricSecurityKey key, String algorithm, Boolean willCreateSignatures) 
    --- End of inner exception stack trace --- 
    at System.IdentityModel.Tokens.AsymmetricSignatureProvider..ctor(AsymmetricSecurityKey key, String algorithm, Boolean willCreateSignatures) 
    at System.IdentityModel.Tokens.SignatureProviderFactory.CreateProvider(SecurityKey key, String algorithm, Boolean willCreateSignatures) 
    at System.IdentityModel.Tokens.SignatureProviderFactory.CreateForVerifying(SecurityKey key, String algorithm) 
    at System.IdentityModel.Tokens.JwtSecurityTokenHandler.ValidateSignature(SecurityKey key, String algorithm, Byte[] encodedBytes, Byte[] signature) 
    at System.IdentityModel.Tokens.JwtSecurityTokenHandler.ValidateSignature(JwtSecurityToken jwt, Byte[] signatureBytes, IEnumerable`1 signingTokens)'. 

System.NotSupportedException: Crypto алгоритм 'http://www.w3.org/2001/04/xmldsig-more#hmac-sha256 '

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

Любые идеи, как включить sha256 для этого контекста?

ОБНОВЛЕНИЕ: Поскольку у меня не было никакого движения по этой проблеме (кроме получения значка перекатистой стороны), я добавлю несколько подробностей. Возможно, кто-то может помочь мне в работе, где возникает проблема. Я должен предположить, что, поскольку никто другой не сталкивается с этой проблемой, должна быть ошибка пользователя с моей стороны где-то. Скажите, пожалуйста, если что-то звучит некорректно.

Я предполагаю, что, поскольку мы не выполняем проверку jwt, возможно, это имеет какое-то отношение к сертификату на машине проверки/idP.

1. Я создал сертификат подписи sha256 для idP и поместил его в персональные сертификаты на idP.
2. Я экспортировал открытый ключ этого сертификата и поместил в папку Cert of доверенных людей моей машины проверки.
3. Я затем запустить следующий код на моей проверке машине после получения маркеров от моего IDP:

Пример:

var jwtToken = response.AccessToken; 
var store = new X509Store(StoreName.TrustedPeople, StoreLocation.LocalMachine); 
store.Open(OpenFlags.ReadOnly); 
X509Certificate2 cert = store.Certificates.Find(X509FindType.FindByThumbprint, "thinktecture identityserver 2.Configuration => Key Configuration => Signing Thumbprint>", false)[0]; 
store.Close(); 
var tokenHandler = new JwtSecurityTokenHandler(); 
var validationParameters = new TokenValidationParameters 
       { 
        AllowedAudience = "<thinktecture identityserver 2.Configuration => Relying Party => Realm/Scope Name>", 
        ValidIssuer = "<thinktecture identityserver 2.Configuration => General Configuration => Site ID>", 
        SigningToken = new X509SecurityToken(cert) 
       }; 

ClaimsPrincipal claimsPrincipal = tokenHandler.ValidateToken(jwtToken, validationParameters); 

Обратите внимание мое использования следующих заполнителей, показывая, где данные поступают от:

• thinktecture identityserver 2.Configuration => Key Configuration => Вход Thumbprint
• thinktecture identityserver 2.Configuration => полагающаяся сторона => Realm/Scope Name
• thinktecture identityserver 2.Configuration => Общие настройки => ID сайта

Что вы можете увидеть что я делаю не так в этом случае?

UPDATE 2

Я столкнулся с этим кодом: http://pastebin.com/DvQz8vdb и после запуска моего JWT через него я дал мне ту же ошибку: В основном это говорит, что поддерживает только «RS256», «HS384», или «HS512 ». Возможно, это моя проблема .. мой JWT возвращается HS256, а не RS256 или HS> 256 (384/512)

Как изменить алгоритм подписи с HS256 на HS512?

И в этот момент я думаю, что мы вернулись к проблеме сервера удостоверений?

Answer 1

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

Я решил проблему с помощью Симметричного ключа подписи для проверки jwt, а не сертификата подписи, найденного в разделе «Конфигурация ключа» IdentityServer.

Answer 2

Раньше в этот старый пост по совпадению, но поскольку у меня была аналогичная проблема почти год назад, я расскажу о своих выводах тогда. В основном способ заставить «IdSrv V2» использовать сертификат подписи - убедиться, что для доверяющей стороны не существует симметричного ключа подписи. Пока он определен, он всегда будет использовать симметричный ключ подписи. См. Мой blog post на нем для более подробной информации.

Надеется, что это может помочь другим в конечный итоге здесь :-)

Answer 3

Я знаю, что это старый вопрос, но я столкнулся с точно такой же проблемой, но нашел connect issue относительно состояния гонки внутри CrptoHelper.GetIdentityFromConfig который что вызывает проблему