Identity3 modern
Identity3 modern
OpenID Connect and OAuth2
OpenID Connect is generally considered to be the future because it has the most potential for modern applications. It was built for mobile application scenarios right from the start and is designed to be API friendly.
OAuth2 is a protocol that allows applications to request access tokens from a security token service and use them to communicate with APIs. This reduces complexity on both the client applications as well as the APIs since authentication and authorization can be centralized.
OpenID Connect and OAuth2 are very similar – in fact OpenID Connect is an extension on top of OAuth2. This means that you can combine the two fundamental security concerns – authentication and API access into a single protocol – and often a single round trip to the security token service.
High Level Features
-
Authentication as a Service
-
Single Sign-on / Sign-out
-
Access Control for APIs Issue access tokens for APIs for various types of clients, e.g. server to server, web applications, SPAs and native/mobile apps.
-
Federation ( Identity Providers )
Client (ClientStore)
A client is a piece of software that requests tokens from IdentityServer - either for authenticating a user or for accessing a resource (also often called a relying party or RP). A client must be registered with the OP.
Examples for clients are web applications, native mobile or desktop applications, SPAs, server processes etc.
User ( UserService )
A user is a human that is using a registered client to access his or her data.
Scope (ScopeStore)
Scopes are identifiers for resources that a client wants to access. This identifier is sent to the OP during an authentication or token request.
By default every client is allowed to request tokens for every scope, but you can restrict that.
IdentityServerServiceFactory
---->> Service Factory
the storage for configuration data or the identity management implementation for validating users’ credentials
Provided implementations
There are two implementations that are provided from IdentityServer core:
DefaultCorsPolicyService
- This implementation can be used if the list of allowed origins to allow is fixed and known at application start. The
AllowedOrigins
property is the collection that can be confgured with the list of origins that should be allowed. - There is also a
AllowAll
property which can be set totrue
to allow all origins.
- This implementation can be used if the list of allowed origins to allow is fixed and known at application start. The
InMemoryCorsPolicyService
- This implementation accepts as a constructor argument a list of
Client
objects. The origins allowed for CORS is configured via theAllowedCorsOrigins
property of theClient
objects. - This implementaion will automatically be registered if the
UseInMemoryClients
configuration extension method is used.
- This implementation accepts as a constructor argument a list of
There is one last implementation provided from IdentityServer3.EntityFramework:
ClientConfigurationCorsPolicyService
- This implementation draws its list of allowed origins from the
AllowedCorsOrigins
property of theClient
objects that are stored in the database. - This implementaion will automatically be registered if the
RegisterClientStore
orRegisterConfigurationServices
extension methods are used.
- This implementation draws its list of allowed origins from the