 Single Sign-On Authentication is required now more than ever. Nowadays, almost every website requires some sort of authentication form to access its features and content. With the number of websites and services rising, a centralized login system has become a necessity. In this video, you'll learn how Single Sign-On Authentication is implemented for the website. Single Sign-On is strictly related to the authentication part of a federated identity system. It only concerns establishing the identity of the user and then sharing that information with each sub-system that requires that data. Basically, a federated identity is a centralized or linked electronic identity and it handles a few concerns. The first one is authentication. This aspect deals with validating the user credentials and establishing the user's identity. It also handles authorization, which is related to access restrictions. Is the user allowed to check X resource or Y resource? Next, we have user attribute exchange. This aspect deals with data sharing across multiple user management systems. For instance, a field such as the user's real name might be present in multiple systems. A federated identity system prevents data duplication by linking their related attributes. Lastly, we have user management, which is related to user administration, like create, delete, and update users. A federated identity system usually provides the means for administrators and users to handle accounts across different domains and subsistence. But now let's go back to Single Sign-On. Sooner or later, web development teams face the same issue. You have developed an application at domain X and now you want your new deployment at domain Y to use the same login information that you had on domain X. In fact, you want more. You want users that are already logged in in domain X to be also logged in in domain Y. And this is really what Single Sign-On is all about. Let's take a look of how a non-Single Sign-On scenario would be like. As a user, you would browse to domainX.com where you would be required to enter your login information and be authenticated. And then your browser will then store a cookie. Then the same user browsers to domainY.com where they are also required to enter their login credentials and authenticate it. And the browser stores a cookie again. Now as you can see, the user had to enter their credentials twice and be logged in twice. The solution to this problem is to share session information across domains. However, for security reasons, browsers enforce a policy called Same Origin Policy, which dictates that cookies and any other local store data can only be accessed by its creator. And by creator, we mean the domain that initially requested that data to be saved in the first place. In other words, domainX cannot access the cookies that are stored on domainY, or vice versa. Luckily, Single Sign-On solves this issue on one way or the other by sharing session information across domains. Different Single Sign-On protocols share information in different ways. But the end concept is the same. There is a central domain where the authentication is performed and then the session is shared across different domains. For instance, the central domain can generate fine JSON web tokens, which can be encrypted using JSON web encryption. This token may then be passed to a client and used by the authentication server and any other domain. The token can be passed to the original domain via redirect. And it will contain all the necessary information required to validate the user's identity in the domain required authentication. As the token is signed, it cannot be modified by the client in any way. The way it works is that whenever a user needs to be authenticated, they are redirected to the authentication server. As users are already logged in in that domain, they can be immediately redirected to the original domain with all the necessary information and authentication token. Let's go ahead and take a look how a typical single sign-on flow would look like. A user would browse to domainx.com, which then will redirect them to the authentication server. Two things can happen in the authentication server. One, the user can be logged in for the first time, enter the credentials, and the authentication server will validate them. Or two, it's not the first time that the user is there and there is already a cookie available. Once the user is authenticated in the authentication server, they are redirected back together with a token to domainx.com. Domainx.com will then use that token to authenticate within its own domain. And it will store a cookie in the browser's local storage of domainx. Now, when the user wants to access another domain within this system, they would navigate, for example, to domainy.com. Domainy.com will then redirect the user to the authentication server, and because they have already signed in, there will be a cookie available in the browser's cookie storage. The authentication server will send a token and redirect the user back to domainy.com, which then will be used to authenticate the user in that domain. And finally, it will store a cookie in its local browser storage. If you've been doing some research about single sign-on, you've probably found out that there are multiple protocols and ways to implement it. There's OpenIDConnect, FacebookConnect, SAML, and many others. You should choose whatever is simplest for your developer efforts. For instance, SAML is really well-established in enterprise environment, so you might want to go with that. If you think you will need to integrate your development in more than one alternative, don't worry, there are already solutions available for you. In fact, Out0 has one of those solutions available. If you're already using Out0 for your development, you will know how easy it is to integrate our solution into your system. You can go ahead and take a look to our single sign-on documentation and our code samples out there. The Out0 solution works as a bridge between different single sign-on frameworks. So wherever your existing applications are using right now, using Out0 will be super easy to integrate. If you remember from the previous diagram that we talked about, basically the change in there, it would be that what we used to call the authentication server would now be Out0. In the end, single sign-on solves a big problem, and that is authentication and big decentralized systems. There are frameworks out there that you can use to implement single sign-on, but Out0 will make your life way more easier. Let me know what you think about this video in the comments below. Thanks for watching!