{"id":4308,"date":"2021-11-18T10:00:00","date_gmt":"2021-11-18T15:00:00","guid":{"rendered":"https:\/\/www.jumpcloud.com\/blog\/?p=4308"},"modified":"2023-01-06T15:55:43","modified_gmt":"2023-01-06T20:55:43","slug":"single-sign-on-actually-works","status":"publish","type":"post","link":"https:\/\/jumpcloud.com\/blog\/single-sign-on-actually-works","title":{"rendered":"How Single Sign-On (SSO) Authentication Works"},"content":{"rendered":"\n
Modern single sign-on (SSO)<\/a> is an authentication method that enables users to securely and efficiently authenticate to a variety of IT resources such as networks, devices, servers, applications, and services using a single set of credentials. At JumpCloud\u00ae<\/sup>, we refer to modern SSO as True Single Sign-OnTM<\/sup> compared to the traditional and outdated version of web application SSO. <\/p>\n\n\n\n The difference here is that web app SSO only connects users to web apps, while True SSO<\/a>TM <\/sup>allows users to connect to virtually any IT resource via SSO by a variety of open protocols. This allows IT admins to manage identities and access no matter what resources live within their IT ecosystem. Modern SSO also serves other purposes \u2014 it improves security along with user and IT productivity, reduces password fatigue<\/a> and management, streamlines the user experience, prevents Shadow IT<\/a>, and more.<\/p>\n\n\n\n In this article, we\u2019ll dive into an overview of how single sign-on works, protocols you need to be aware of, how to choose the protocols you need, and how JumpCloud\u2019s SSO solution works.<\/p>\n\n\n\n Single sign-on allows users to authenticate to various IT resources with one username and password combination based on a trusted relationship between each resource and an identity provider (IdP). Typically, this relationship\u2019s foundation stems from a certificate that is exchanged between the resource (or service provider (SP)) and the IdP when configuring SSO. <\/p>\n\n\n\n The certificate’s purpose is to create a trust relationship between the SP and the IdP to verify the integrity of the information being exchanged. During the single sign-on process, the identity data being pushed from the IdP to the SP takes the form of tokens which contain identifying bits of information about the user. These tokens can be signed with the certificate used when creating the trust relationship.<\/p>\n\n\n\n When a user signs into an SSO provider\u2019s portal, the IdP tracks that the user is already authenticated, usually via a session cookie. From there, any resource connected via SSO will check with the SSO provider<\/a> when a user attempts to access that resource. If the IdP verifies the user based on their initial login through the portal, a token will be passed to the resource, and the federated identity<\/a> is used to complete the sign-in process. However, if the user has not signed in to the main SSO portal or their session has expired, they will be prompted to log in before being granted access to any SSO connected resources.<\/p>\n\n\n\n Authentication tokens are a crucial part of the single sign-on process \u2014 they enable identity verification to take place separately from other cloud services. These authentication tokens can take different forms while following varying communication standards to ensure validity. One extremely common authentication token standard (also referred to as an authentication protocol) is called Security Assertion Markup Language (SAML)<\/a>, which is used for web app authentication. <\/p>\n\n\n\n A couple other common authentication and\/or authorization protocols are the Lightweight Directory Access Protocol (LDAP) and Open Authentication (OAuth2).<\/p>\n\n\n\n The LDAP protocol<\/a> was originally designed for facilitating on-prem authentication and other on-prem server processes, and continues to be used to authenticate user access to legacy systems and applications.<\/p>\n\n\n\n When LDAP and SSO<\/a> are used together, a user enters their credentials and the details of the user\u2019s identity are sent to a security server for authentication. After that, the security server sends the info to the LDAP server which then utilizes the given credentials to attempt to authenticate the user. Essentially, LDAP is an authentication protocol used to cross-check information on the server end.<\/p>\n\n\n\n LDAP is considered a legacy protocol but still has a variety of common use cases including authenticating Linux-based applications, OpenVPN, Jenkins, Kubernetes, Docker, Atlassian Jira and Confluence, and commercially distributed NAS appliances like Synology or QNAP. <\/p>\n\n\n\n Before we can answer this question, it\u2019s important to call out the difference between authentication and authorization. Authentication<\/em> has to do with user identity, whereas authorization<\/em> has to do with user privileges. This is an important distinction to make when discussing OAuth2\u2019s role in web app single sign-on.<\/p>\n\n\n\n While SAML is an authentication<\/em> protocol that extends user credentials to the cloud and other web applications using the Extensible Markup Language (XML) format, OAuth2<\/a> is an authorization<\/em> protocol that\u2019s more tailored toward access scoping, which is the practice of allowing only the bare minimum of access within the resource\/app that an identity requires once verified. OAuth2 is specifically ideal for web and mobile apps and is generally used by the apps themselves in conjunction with an IdP. OAuth2 also allows for sign-in mechanisms like \u201cSign in with Google,\u201d streamlining the login process even further. <\/p>\n\n\nHow Does SSO Work?<\/h2>\n\n\n\n
Different SSO Authentication Protocols<\/h2>\n\n\n\n
How Does LDAP Work Within SSO?<\/h3>\n\n\n\n
How Does OAuth2 Work Within SSO?<\/h3>\n\n\n\n