### Core Concept
* With self-hosted identity, a SaaS provider will select the identity tooling/service that best aligns with the needs of their environment. They will define all the moving parts of the authentication flow, including defining the custom claims/attributes that will be associated with each user within the scope of the identity model. This approach gives the SaaS provider the greatest control over their identity experience, enabling them to provide the business and customers with a rich collection of authentication and tiering options.

### Key Considerations
* Self-hosted identity can be tightly woven into your overall tenant onboarding process where you can better orchestrate the creation, management, and lifecycle of the users in your SaaS environment. 
* Many identity providers offer a range of configuration options for their authentication experience. Support for MFA, password expiration policies, password format policies, and host of other options are often provided. In a self-hosted model, you can selectively offer these features to tenants. For example, your basic tier tenants may be provided a fixed combination of more limited options, while your premium tier tenants could be allowed to configure the full set of options. So, I might allow my premium tier tenants to turn on/off any of the features listed above.
* Adding claims/attributes to your identity in your self-hosted model can be used to associate key data with your SaaS identity. Tenant identifier, roles, etc. are all natural attributes that make sense to bind to your identity. However, you should draw a hard line between what is needed for your SaaS identity and what is needed to introduce general purpose role configuration into your environment. If you have application constructs that are continually be added/updated to enable application paths, those attributes and configuration should be managed outside the scope of your identity experience. This is where traditional RBAC and other frameworks can fill this need.
* Some self-hosted identity solutions may offer a range of constructs for representing and grouping users. For example, Amazon Cognito has the notion of User Pools and groups. As part of your architecture, for example, you may want to put all users into a single user pool or you may choose to place them in a separate pools. In each of these cases you have to considering the scalability of the model along with the tiering needs of your environment. You might offer premium tier tenants their own user pool and put all the remaining users in their own pool. There are lots of permutations here. The key here is to identify a grouping strategy that best aligns with the needs of the business and how it may influence the auth flow of your experience.
* A self-hosted identity provider often serves as the overall tenant user management of your system. As you look at this service, you’ll want to think beyond the authentication experience and consider how this will shape and influence the overall user management experience of your tenants. What data and actions will need to be supported to support the configuration and management of all the system’s users. Will identity be managed in one location and all the other capabilities of identity be managed through services in your application?