Authentication verifies that a person, computer, or software is what it claims to be. For a web API, it answers “Who is calling?” before the API decides what that caller may do. section 9.1.1 section 9.6
Consider a board-game API with endpoints that add or delete games, domains, and mechanics. Leaving those endpoints open lets anyone change the data. Authentication identifies callers so the API can distinguish a known user from an anonymous one; authorization then determines whether that user has permission to make the change. section 9.0 section 9.1.2
A typical access flow is:
- Give anonymous callers only limited access, such as public content and a way to log in. section 9.1.2
- Authenticate a caller whose login attempt succeeds. section 9.1.2
- Check the caller’s permissions and allow or deny access to the restricted resource. section 9.1.2
Use the flow diagram to trace how identifying a user and deciding access work together. A request for a restricted resource can also be denied while the caller is still anonymous. section 9.1.2
In an ASP.NET Core API, Identity provides abstractions for managing user accounts alongside roles, claims, tokens, and policies. User accounts and JSON Web Tokens are authentication options; authorization checks can then restrict endpoints. The choice needs care: a bearer token can carry information used for authorization without authenticating the client on every request, but anyone who gains access to the token may pose a security problem. section 9.0 section 9.6
Why identify the caller?
A user logging into a service is a familiar authentication example. Identifying users uniquely can also help attribute actions to their authors, support monitoring, and determine whether someone is logged in. Shared credentials weaken that accountability because actions cannot be reliably attributed to one person. section 9.1.1
