https://docs.microsoft.com/en-us/aspnet/web-api/overview/security/individual-accounts-in-web-api
Individual accounts provide two ways for a user to log in:
- Local login. The user registers at the site, entering a username and password. The app stores the password hash in the membership database. When the user logs in, the ASP.NET Identity system verifies the password.
- Social login. The user signs in with an external service, such as Facebook, Microsoft, or Google. The app still creates an entry for the user in the membership database, but does not store any credentials. The user authenticates by signing into the external service.
This article looks at the local login scenario. For both local and social login, Web API uses OAuth2 to authenticate requests. However, the credential flows are different for local and social login.
First, we need to define some OAuth2 terminology.
- Resource. Some piece of data that can be protected.
- Resource server. The server that hosts the resource.
- Resource owner. The entity that can grant permission to access a resource. (Typically the user.)
- Client: The app that wants access to the resource. In this article, the client is a web browser.
- Access token. A token that grants access to a resource.
- Bearer token. A particular type of access token, with the property that anyone can use the token. In other words, a client doesn't need a cryptographic key or other secret to use a bearer token. For that reason, bearer tokens should only be used over a HTTPS, and should have relatively short expiration times.
- Authorization server. A server that gives out access tokens.
An application can act as both authorization server and resource server. The Web API project template follows this pattern.
新建一个web api项目,选择模板项目,并且勾选授权
Understanding the Individual Accounts Project Template
When you select Individual Accounts in the ASP.NET Web Application project template, the project includes:
- An OAuth2 authorization server.
- A Web API endpoint for managing user accounts
- An EF model for storing user accounts.
Here are the main application classes that implement these features:
AccountController
. Provides a Web API endpoint for managing user accounts. TheRegister
action is the only one that we used in this tutorial. Other methods on the class support password reset, social logins, and other functionality.ApplicationUser
, defined in /Models/IdentityModels.cs. This class is the EF model for user accounts in the membership database.ApplicationUserManager
, defined in /App_Start/IdentityConfig.cs This class derives from UserManager and performs operations on user accounts, such as creating a new user, verifying passwords, and so forth, and automatically persists changes to the database.ApplicationOAuthProvider
. This object plugs into the OWIN middleware, and processes events raised by the middleware. It derives from OAuthAuthorizationServerProvider.
扩展阅读
- ASP.NET Identity
- Understanding Security Features in the SPA Template for VS2013 RC. MSDN blog post by Hongye Sun.
- Dissecting the Web API Individual Accounts Template–Part 2: Local Accounts. Blog post by Dominick Baier.
- Host authentication and Web API with OWIN. A good explanation of
SuppressDefaultHostAuthentication
andHostAuthenticationFilter
by Brock Allen. - Customizing profile information in ASP.NET Identity in VS 2013 templates. MSDN blog post by Pranav Rastogi.
- Per request lifetime management for UserManager class in ASP.NET Identity. MSDN blog post by Suhas Joshi, with a good explanation of the
UserManager
class.
RequestContext.Principal
Before I even get into the main part of this post, a side note on the identity of the calling user: Web API 2 introduced a new RequestContext class that contains a Principal property. This is now the proper location to look for the identity of the caller. This replaces the prior mechanisms of Thread.CurrentPrincipal and/or HttpContext.User. This is also what you would assign to if you are writing code to authenticate the caller in Web API.