Walidacja JWT platformy ASP.NET Core 2.0 kończy się niepowodzeniem z błędem "Autoryzacja nie powiodła się dla użytkownika: (zerowy)" błąd

Question

Używam aplikacji ASP.NET Core 2.0 (Web API) jako wydawcy JWT do generowania tokena zużywanego przez aplikację mobilną . Niestety ten token nie może zostać sprawdzony przez jeden kontroler, a może zostać zweryfikowany przez inny (przy użyciu tego samego ustawienia sprawdzania poprawności w obrębie tej samej aplikacji core asp.net core 2.0).

Mam więc token, który jest ważny i może zostać odkodowany, ma wszystkie wymagane roszczenia i znaczniki czasu. Ale jeden punkt końcowy przyjmuje ją, podczas gdy inny daje mi 401 błędów i debugowania wyjście:

Microsoft.AspNetCore.Authorization.DefaultAuthorizationService: INFORMACJA: Autoryzacja nie powiodła się dla użytkowników: (null).

[40m[32minfo[39m[22m[49m: Microsoft.AspNetCore.Authorization.DefaultAuthorizationService[2] 
     Authorization failed for user: (null). 
Microsoft.AspNetCore.Authorization.DefaultAuthorizationService:Information: Authorization failed for user: (null). 
[40m[32minfo[39m[22m[49m: Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker[3] 
     Authorization failed for the request at filter 'Microsoft.AspNetCore.Mvc.Authorization.AuthorizeFilter'. 
Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker:Information: Authorization failed for the request at filter 'Microsoft.AspNetCore.Mvc.Authorization.AuthorizeFilter'. 
Microsoft.AspNetCore.Mvc.ChallengeResult:Information: Executing ChallengeResult with authentication schemes(). 
[40m[32minfo[39m[22m[49m: Microsoft.AspNetCore.Mvc.ChallengeResult[1] 
     Executing ChallengeResult with authentication schemes(). 
[40m[32minfo[39m[22m[49m: Microsoft.AspNetCore.Authentication.JwtBearer.JwtBearerHandler[12] 
     AuthenticationScheme: Bearer was challenged. 
Microsoft.AspNetCore.Authentication.JwtBearer.JwtBearerHandler:Information: AuthenticationScheme: Bearer was challenged. 
[40m[32minfo[39m[22m[49m: Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker[2] 
     Executed action MyController.Get (WebApi) in 72.105ms 
Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker:Information: Executed action MyController.Get (WebApi) in 72.105ms 
Microsoft.AspNetCore.Hosting.Internal.WebHost:Information: Request finished in 271.077ms 401 
[40m[32minfo[39m[22m[49m: Microsoft.AspNetCore.Hosting.Internal.WebHost[2] 
     Request finished in 271.077ms 401 

Moja konfiguracja walidacja jest poniżej:

var secretKey = Configuration["Authentication:OAuth:IssuerSigningKey"]; 
var signingKey = new SymmetricSecurityKey(Encoding.ASCII.GetBytes(secretKey)); 
var tokenValidationParameters = new TokenValidationParameters 
{ 
    ValidateIssuerSigningKey = true, 
    IssuerSigningKey = signingKey, 
    ValidateIssuer = true, 
    ValidIssuer = Configuration["Authentication:OAuth:Issuer"], 
    ValidateAudience = true, 
    ValidAudience = Configuration["Authentication:OAuth:Audience"], 
    ValidateLifetime = true, 
    ClockSkew = TimeSpan.Zero, 
}; 

services.AddAuthentication(options => 
{ 
    options.DefaultScheme = JwtBearerDefaults.AuthenticationScheme; 
    options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme; 
    options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme; 
}).AddJwtBearer(options => 
{ 
    options.RequireHttpsMetadata = false; 
    options.TokenValidationParameters = tokenValidationParameters; 
}); 

Te dwa punkty końcowe są identyczne, po prostu żyją w różnych kontrolerów, zarówno oznaczona atrybutem Authorize.

Jak to możliwe?

Answer 1

Sekwencja sprawozdania dodać w funkcji configure ma znaczenie. Upewnij się, że

app.UseAuthentication(); 

przychodzi przed

app.UseMvc(); 

To mogło być problem?

Answer 2

Można spróbować to zamiast:

.AddJwtBearer(options => 
{ 
    AutomaticAuthenticate = true, 
    AutomaticChallenge = true, 
    options.RequireHttpsMetadata = false; 
    options.TokenValidationParameters = tokenValidationParameters; 
});' 

Answer 3

spróbować tego w startup.cs

services.AddAuthentication(options => 
     { 
      options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme; 
      options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme; 
     }).AddJwtBearer(opts => ... 

Answer 4

I dodaje:

app.UseAuthentication(); 

W Startup.Configure() i że rozwiązano ten problem dla mnie.

referencyjny: Auth 2.0 Migration announcement

Answer 5

Wydaje się, że to zachowanie, które otrzymujesz, gdy Twój JWT nie jest poprawnie zatwierdzony. Miałem ten problem w wyniku wpisując "Bearer (JWT)" zamiast "doręczyciela (JWT)" w nagłówku

Answer 6

w twojej startup.cs metoda ConfigureServices Jeśli dodać

services.AddAuthentication(options => 
      { 
       options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme; 
      }).AddJwtBearer(options => ... 

Objaśnienie : Podczas korzystania z [Autoryzuj] na kontrolerze domyślnie wiąże się z pierwszym systemem autoryzacji.

options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme; 

Dzięki temu ustawiasz domyślne uwierzytelnianie na okaziciela JWT.

dodatkowo można dodać

options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme; 

linia ta, jak zapobiec uzyskiwanie 404 Not Found błędów podczas korzystania z JWTs tożsamość. Jeśli używasz tożsamości, DefaultChallengeScheme spróbuje przekierować cię do strony logowania, która jeśli nie istnieje, spowoduje, że 404 nie zostanie znalezione, a nie 401 nieautoryzowane. poprzez ustawienie DefaultChallengeScheme do JwtBearerDefaults.AuthenticationScheme na nieuprawnione nie będzie już próbować przekierować do strony logowania

Jeśli używasz uwierzytelniania Cookie z uwierzytelnianiem JWT w tagu [Autoryzacja] można określić, co chcesz authenticationScheme . na przykład:

[Authorize(AuthenticationSchemes = JwtBearerDefaults.AuthenticationScheme)]