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

•  IdentityServer up and running 

• IdentityServer Options

 

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 to true to allow all origins.
• InMemoryCorsPolicyService
  • This implementation accepts as a constructor argument a list of Client objects. The origins allowed for CORS is configured via the AllowedCorsOrigins property of the Client objects.
  • This implementaion will automatically be registered if the UseInMemoryClients configuration extension method is used.

There is one last implementation provided from IdentityServer3.EntityFramework:

• ClientConfigurationCorsPolicyService
  • This implementation draws its list of allowed origins from the AllowedCorsOrigins property of the Client objects that are stored in the database.
  • This implementaion will automatically be registered if the RegisterClientStore or RegisterConfigurationServices extension methods are used.