Providers use SAML to relay credentials between an identity provider (IdP), which contains the credentials to verify a user, and a service provider (SP), which is the resource that requires authentication. Information about a user or group is stored within attributes. <\/p>\n\n\n\n
Let\u2019s take a deeper dive into each of SAML\u2019s main components:<\/p>\n\n\n\n
Identity Provider<\/h3>\n\n\n\n
IdPs are services that create, maintain, and manage digital identities. They function as the single source of truth that verifies login credentials across applications, networks, and services. An IdP protects the integrity of user credentials and federates user identity across the web.<\/p>\n\n\n\n
Client<\/h3>\n\n\n\n
This is the user that authenticates with credentials managed by an IdP, becoming an authenticated user on a service.<\/p>\n\n\n\n
Attributes<\/h3>\n\n\n\n
SAML assertions<\/a> are messages sent from an IdP to a service provider that are used to set security requirements for the transaction, as well as to authenticate, authorize, and determine the level of permissions to establish for each client. <\/p>\n\n\n\n Assertions contain attributes such as \u201cdepartment,\u201d \u201cemail,\u201d and \u201crole,\u201d which are used to enforce access management and control. Sometimes, custom attributes are used to work with specialized software.<\/p>\n\n\n\n Service providers receive and accept\/deny assertions from IdPs for a client and grants access to whatever resource the user needs. SPs send requests to IdPs to begin the authentication process. <\/p>\n\n\n\n The client\u2019s assertion is sent back in response. The order in which this happens is sometimes reversed with the IdP initiating the sign-in flow to assert user identity.<\/p>\n\n\n\n Now that we\u2019ve covered the basics, here\u2019s how it works as a whole. SAML uses extensible markup language (XML) metadata documents as its SAML tokens for an assertion of a user\u2019s identity. The process of SAML authentication and authorization (AuthN and AuthZ) is as follows:<\/p>\n\n\n\n Developers can leverage SAML plugins to ensure their app or resource follows desireable single sign-on processes<\/a> to simplify their user\u2019s login experience and ensure security practices are laid in place to leverage a common identity strategy.<\/p>\n\n\n\n That way, only an identity with the proper credentials\/assertion can access an application. Additionally, SAML can be used to control what an identity can access in an application. Access is only a user click away.<\/p>\n\n\n\n OAuth, or Open Authentication, is also an AuthN\/AuthZ protocol used for secure authentication needs. Like SAML, OAuth requires an identity provider as the source of truth for authenticating user access. OAuth uses its own XML documentation for authentication tokens, but can also use JavaScript Object Notation (JSON) for tokens as well. Here are its main components: <\/p>\n\n\n\n We\u2019ve all signed into a service that offers to log you in using an existing credential from a large social media site versus creating a new account with credentials that are unique to that site. That social media account is yours, and you\u2019re the resource owner.<\/p>\n\n\n\n This is the site\/application that utilizes the social media account you own (or whatever other account is listed as an option). It uses OAuth rather than storing your credentials and redirects the user to a login via an authorization server before it grants access.<\/p>\n\n\n\n A resource server is an API server that stores data that the client application is requesting. This server handles requests after the client application has been granted an access token.<\/p>\n\n\n\n The authorization server is at the center of the OAuth workflows and grants consent, fielding requests for access and granting temporary tokens that a client \u201ccashes in\u201d at a resource server.<\/p>\n\n\n\n The OAuth process is detailed in the following diagram:<\/p>\n\n\n\n In general, SAML and OAuth are very similar: they both authenticate and authorize access regarding applications hosted in a web browser. When it comes to practice, though, they are obviously very different.<\/p>\n\n\n\n Both of these authentication patterns enable SSO to eliminate unnecessary usernames and passwords, scale well for the web, and are based on open standards to verify identities and grant access to protected resources through centralized management.<\/p>\n\n\n\n IT admins benefit from easier onboarding and delegated user management. The standards can even be complementary and encourage interoperability. For example, the OAuth assertion flow makes it possible for authentication servers to receive authorization grants from SAML-trusted IdPs.<\/p>\n\n\n\n Imagine that you\u2019ve purchased tickets to a ballgame. SAML is akin to a ticket that a ticket taker authenticates upon entry, granting access to the venue until there\u2019s a winner (or a tie). OAuth is the package that your ticket purchases: e.g., you\u2019re sitting in a section that entitles you to private bathrooms, catering, and the like. You\u2019re authorized to have those perks.<\/p>\n\n\n\n There are some privacy concerns associated with using third-party OAuth services. Governmental regulatory regimes, such as GDPR, require website operators to declare which services use and collect data. Organizations that use \u201cfree\u201d OAuth services may lack autonomy and control, and the online activities of employees may be tracked by advertisers.<\/p>\n\n\n\n SAML is designed for situations like web app SSO solutions, where a central identity provider and an app are in communication and SAML facilitates the AuthN\/AuthZ between them. OAuth is generally used by the applications themselves, using external IdPs to authenticate access and authorize permissions.<\/p>\n\n\n\n Another way to think about the difference is that SAML can generally be thought of as user centric whereas OAuth tends to be more application centric. For example, a user will log in to their single sign-on service and subsequently have access to their roster of SAML-based applications. <\/p>\n\n\n\n With OAuth, a user will generally authenticate with each individual service and the application will have a one-to-one mapping with an IdP.<\/p>\n\n\n\n When it comes to an organization\u2019s identity management, both authorization protocols are useful, and, while not quite usable in concert, they can coexist peacefully. Because of that, however, it might be difficult to find an option for SAML and OAuth AuthN\/AuthZ that isn\u2019t a one-off point solution.<\/p>\n\n\n\n OAuth is more tailored toward access scoping than SAML. Access scoping is the practice of allowing only the bare minimum of access within the resource\/app an identity requires once verified. For instance, OAuth is often used when a web browser requests access to your system\u2019s microphone and camera. <\/p>\n\n\n\n This makes OAuth (specifically OAuth2) ideal for web\/mobile apps, especially ones that can use Google, Facebook, or some other similar identity provider as a source of truth.<\/p>\n\n\n\n There is an option available, a cloud directory service, that organizations can use to facilitate both SAML and OAuth usage for identity management. This solution is called the JumpCloud Directory Platform<\/a>, the first cloud directory service and identity provider. <\/p>\n\n\n\n JumpCloud natively uses the SAML protocol to directly communicate with hundreds of applications a la single sign-on. JumpCloud also directly integrates with Google Workspace and Office 365 identities, meaning that it can control application access through OAuth as well, leveraging those sign-in mechanisms (e.g., \u201cSign in with Google\u201d) using OAuth under the covers. JumpCloud provides Push and TOTP MFA<\/a> services to add another layer of authentication.<\/p>\n\n\n\n Beyond SAML and OAuth, JumpCloud also provides an additional array of standard authentication and authorization mechanisms such as LDAP and RADIUS<\/a> to ensure users can leverage a single set of credentials across all of their resources ranging from web apps to on-prem resources like NAS appliances or legacy applications. <\/p>\n\n\n\n The credentials also are leveraged for secure access to their macOS, Windows, and Linux systems, ensuring the greatest totality of coverage a user\u2019s identity can access securely. And, since it is a centralized identity provider with these capabilities, it offers admins the ability to provide their users with a single set of credentials to access all of these resources, all managed from a single cloud admin portal.<\/p>\n\n\n\n If you would like to learn more about SAML, OAuth, and JumpCloud in general, please contact us<\/a>. You can also explore what JumpCloud has to offer by scheduling a free personalized demo<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":" What\u2019s the difference between SAML and OAuth? It\u2019s a common question for companies looking to extend their identities to the cloud.<\/p>\n","protected":false},"author":150,"featured_media":34301,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_oasis_is_in_workflow":0,"_oasis_original":0,"_oasis_task_priority":"","inline_featured_image":false,"footnotes":""},"categories":[2781,2337],"tags":[2647,2398,2397,2698,2395,2391],"collection":[2779,2780],"platform":[],"funnel_stage":[3016],"coauthors":[2535],"acf":[],"yoast_head":"\nService Provider<\/h3>\n\n\n\n
![\"\"](\"https:\/\/jumpcloud.com\/\/wp-content\/uploads\/2022\/05\/1.2-1.png\")
<\/figure>\n\n\n\nHow Does OAuth Work?<\/h2>\n\n\n\n
Resource Owner<\/h3>\n\n\n\n
Client<\/h3>\n\n\n\n
Resource Server<\/h3>\n\n\n\n
Authorization Server<\/h3>\n\n\n\n
![\"\"](\"https:\/\/jumpcloud.com\/\/wp-content\/uploads\/2022\/05\/2.2-1.png\")
<\/figure>\n\n\n\nSAML vs. OAuth<\/h2>\n\n\n\n
Similarities<\/h3>\n\n\n\n
Differences<\/h3>\n\n\n\n
How Are SAML and OAuth Used?<\/h3>\n\n\n\n
Can SAML and OAuth Be Used Together?<\/h3>\n\n\n\n
Learn More<\/h2>\n\n\n\n