2014-04-22 11 views
21

Próbuję zrozumieć uwierzytelnianie i autoryzację kont indywidualnych Asp.net Web Api. Widziałem kilka samouczków w Internecie, w tym this one. W skrócie, gdy agent użytkownika podaje nazwę użytkownika i hasło, interfejs API wydaje token, którego klient użyje w kolejnych wywołaniach interfejsu API w celu identyfikacji. Agent użytkownika odbiera token, wysyłając żądanie, zwykle w celu: http://example.com/Token. Ścieżka wydaje się być ustawiony w klasie Startup tak:W architekturze Web Api/Owin, gdzie są obsługiwane żądania do "/ token"?

TokenEndpointPath = new PathString("/Token") 

Mój problem polega na tym, że nie mogę znaleźć żadnych metod kontrolera, które pasują do tej ścieżki. Jak to działa?

Odpowiedz

27

Po utworzeniu nowego projektu z indywidualnym uwierzytelnieniem w środowisku ASP.NET rozwiązanie jest tworzone za pomocą dostawcy OAuth w celu obsługi żądania uwierzytelnienia.

Jeśli spojrzysz na swoje rozwiązanie, powinieneś zobaczyć Folder dostawców z klasą ApplicationOAuthProvider.

Ta klasa implementuje całą logikę do uwierzytelniania użytkowników w Twojej witrynie. Konfiguracja jest ustawiona na Startup, aby umożliwić dostosowanie punktu końcowego url poprzez OAuthOption.

OAuthOptions = new OAuthAuthorizationServerOptions 
{ 
    TokenEndpointPath = new PathString("/Token"), 
    Provider = new ApplicationOAuthProvider(PublicClientId), 
    AuthorizeEndpointPath = new PathString("/api/Account/ExternalLogin"), 
    AccessTokenExpireTimeSpan = TimeSpan.FromDays(14), 
    AllowInsecureHttp = true 
}; 

Właściwości Path TokenEndPoint zdefiniowany adres URL, który będzie zwolniony metodę GrantResourceOwnerCredentials z GrandResourceOwnerCredentials.

Jeśli używasz Skrzypek do uwierzytelniania i korzystać z tego rodzaju ciała

grant_type=password&username=testUserName&password=TestPassword 

należy przekazać w następujący sposób:

public override async Task GrantResourceOwnerCredentials(OAuthGrantResourceOwnerCredentialsContext context) 
    { 
     var userManager = context.OwinContext.GetUserManager<ApplicationUserManager>(); 

     ApplicationUser user = await userManager.FindAsync(context.UserName, context.Password); 

     if (user == null) 
     { 
      context.SetError("invalid_grant", "The user name or password is incorrect."); 
      return; 
     } 

     ClaimsIdentity oAuthIdentity = await user.GenerateUserIdentityAsync(userManager, 
      OAuthDefaults.AuthenticationType); 
     ClaimsIdentity cookiesIdentity = await user.GenerateUserIdentityAsync(userManager, 
      CookieAuthenticationDefaults.AuthenticationType); 

     AuthenticationProperties properties = CreateProperties(user.UserName); 
     AuthenticationTicket ticket = new AuthenticationTicket(oAuthIdentity, properties); 
     context.Validated(ticket); 
     context.Request.Context.Authentication.SignIn(cookiesIdentity); 
    } 

gdzie context.UserName i context.Password są z dane użyte w żądaniu. Po potwierdzeniu tożsamości (tutaj przy użyciu Entity Framework i para userName, Password w bazie danych) do osoby dzwoniącej wysyłany jest token na okaziciela. Ten znacznik na okaziciela może być następnie użyty do uwierzytelnienia w przypadku innych połączeń.

Pozdrawiam.

+0

Dzięki za odpowiedź. Czyści wszystko! – Joe

+0

@Jeremie, dzięki za wyczyszczenie tego. Naprawdę świetne wyjaśnienie i to był mój dokładny problem. Czy każdy może mi powiedzieć, czy używanie tego domyślnego tostera okaziciela oauth jest najlepszym i najbezpieczniejszym sposobem implementacji zabezpieczeń w twoim interfejsie API? Jestem zajęty opracowywaniem API, który będzie wystawiony na działanie Internetu i skonsumowany przez aplikację mobilną angularjs, nad którą obecnie pracuję. Jakieś inne alternatywy? Bardzo doceniane. – fransHbrink

+0

@Jeremie, czy możliwe jest posiadanie wielu adresów URL punktów końcowych, które wszystkie wskazują na tę samą aplikację IAppBuilder. Jeśli nie, to jak możemy mieć wiele punktów końcowych toke w jednej aplikacji webowej? – Jami