An identity provider handles sign-in and user management outside your application. Instead of storing customers’ passwords yourself, you can delegate those responsibilities to a service such as Auth0, Okta, or Azure Active Directory. This can reduce the sensitive user data your application holds, though you still need to choose and configure the provider carefully. section 23.1.2
A central identity provider is especially useful when several apps and APIs need to recognize the same users. An app redirects the user to the provider to sign in. The provider returns tokens to the client, which can send a bearer token to an API. This avoids duplicating sign-in screens and user-management logic across services, and can give users a single-sign-on experience. section 25.1.2
Figure 25.4 An alternative architecture involves using a central identity provider to handle all the authentication and user management for the system. Tokens are passed back and forth among the identity provider, apps, and APIs.
Follow the sign-in path from the app to the central provider, then the token path through the client to an API. section 25.1.2
Choose the arrangement that fits the application:
- Use a third-party provider when you want to delegate user management and authentication. Check its integration instructions—ideally based on OpenID Connect—and understand who owns the resulting user profiles. section 23.1.2
- Use ASP.NET Core Identity when you need to manage users in your own database instead. It supplies much of the authentication and user-management machinery, but the application still needs a working UI and must configure any external providers it uses. section 23.2
A photo service requests access
Suppose a photo-printing service asks to retrieve a user’s Facebook photos. It redirects the user to Facebook to sign in and approve access. OAuth 2.0 handles the delegated access; OpenID Connect builds on it when the service also needs identity information about the signed-in user. The service does not need to collect the user’s Facebook password. section 25.1.3
A provider is not a plug-and-play replacement for application security. Integration can require configuration both in the provider and in your app. APIs must still validate received tokens and decide what permitted actions mean for their own business logic. If a JWT is used, do not assume its contents are secret: JWTs are not encrypted by default. section 23.1.2 section 25.2
