So, now we understand important concepts that have to do with identity, but what exactly do I mean when I say identity?

Well, to quote Microsoft, an identity is a set of things that define or characterize someone or something. An identity is more than just a user's name, it includes any information that is used to authenticate them, such as their username, their password or even the extent of their authorization. In reality, an identity can be thought of like a bubble. For example, my identity is Lee Mucciarone. So, my bubble would be Lee Mucciarone's identity. But within that bubble are a bunch of other bits of information that includes my login information, my devices, my permissions, my applications and more. So, if an identity includes all of those things, what then is an identity provider? Well, simply put an identity provider is responsible for these authentication and authorization concepts we spoke about in the last lecture. Some examples of identity providers include Azure Active Directory, Google, or even Twitter. 

Something important to remember when referring to identity providers is the concept of modern authentication, which is an umbrella term for the authentication and authorization between a client and an application. This modern authentication is also the responsibility of the identity provider. To quote Microsoft again, identity providers create, maintain and manage identity information while offering authentication, authorization and auditing services. Essentially, they are responsible for managing an identity and providing the modern authentication services. Historically, when logging into a resource or a server, a client would simply communicate with the server, enter their credentials, and gain access. The issue with this was if a user had multiple servers they needed to access, they needed a unique username and password specific to each individual server. 

This is where federation and the process of modern authentication come into play. With the addition of modern authentication and a central identity provider, this process changes slightly. The central identity provider maintains that trust relationship with the resources or servers we're talking about earlier. This trust relationship allows a client to authenticate through the provider, thereby nullifying the need of maintaining multiple credentials for different resources. So, a client would authenticate their identity with the identity provider whom then in turn provides that client a security token which it then takes to the server it is attempting to gain access to. This security token holds information about the identity of the client, which is used to validate what resources this token is meant for when the token was created, who the token refers to, and more. Once a server is provided a security token, it can then validate it with the identity provider because of their trust relationship and allows the client access to that resource.