OAuth 2.0 is a framework that\u2019s shaping how web applications communicate with one another and define authorization among them. It\u2019s just one in a suite of modern protocols that IT admins should be aware of, and here we\u2019ll cover how it can be part of your identity and access management (IAM) strategy. <\/p>\n\n\n\n
OAuth 2.0 is an authorization framework released in 2012. It delegates<\/a> authorization to a third-party authorization server via access tokens, rather than passing credentials between a client and the resource server it\u2019s accessing.<\/p>\n\n\n\n The tokens can use either<\/a> XML documents or JavaScript Object Notation (JSON). In essence, OAuth 2.0 outlines<\/a> \u201cauthorization flows for web applications, desktop applications, mobile phones, and living room devices.\u201d\u00a0<\/p>\n\n\n\n OAuth 2.0 can be combined with OpenID Connect for authentication needs, but it is not compatible with its predecessor, OAuth 1.0<\/p>\n\n\n\n Major consumer players in the industry utilize OAuth 2.0 (e.g. Google, Facebook, Twitter, et al). Google APIs use<\/a> it for authentication and authorization, for example.<\/p>\n\n\n\n OAuth can also be used to define the scope<\/a> of access that applications have to accounts. You might be familiar with this as a general user when a third-party service asks for permission to access your Google account and outlines what assets within your account it will access. <\/p>\n\n\n\n It\u2019s also an open standard<\/a> geared toward developer simplicity. Although it\u2019s used for authorization flows to web applications, OAuth differs from another major protocol used to authenticate to web applications, SAML.<\/p>\n\n\n\n SAML (Security Assertion Markup Language) is the protocol that web application single sign-on (SSO) solutions use for secure authentication between identity providers and service providers, aka web applications. <\/p>\n\n\n\n Both SAML and OAuth define a relationship between an app and an identity provider. However, authentication in OAuth is done by another “identity provider,” which can be an application \u2014 so, when someone needs to be authorized in a second application, they can do so by using OAuth from the first application. As an example, a Slack-integrated app might require data from your Slack workspace to complete its tasks. It will use OAuth to ask for permission to access that specified data, rather than using or recording your Slack credentials to gain access or requiring you to create a new set of credentials for it. <\/p>\n\n\n\n OAuth, as mentioned above, is also designed for access scoping, which is the practice of allowing only the bare minimum access within a resource or app.<\/p>\n\n\n\n Although the protocols have different uses, they can be used in conjunction in a comprehensive identity and access management solution \u2014 including in tight integrations between a cloud directory service and productivity suites like G Suite<\/a> and Office 365TM<\/sup>. <\/p>\n\n\n\n OAuth is just one of many in a suite of modern protocols<\/a> that enterprises might need to connect users to the tools they need to get work done each day, as well as SAML, RADIUS, and LDAP.<\/p>\n\n\n\n Ideally, a central identity provider would have the capability to leverage all those protocols as it connects users to systems, applications, files, and networks \u2014 without requiring add-ons to do so. That way, admins could control access to all resources, regardless of operating system or type, from one place. <\/p>\n\n\n\n Learn more about leveraging all these protocols, including OAuth, from a cloud identity provider<\/a>. <\/p>\n\n\n\nBenefits of OAuth<\/h2>\n\n\n\n
Difference between OAuth and SAML<\/h2>\n\n\n\n
OAuth in Identity and Access Management<\/h2>\n\n\n\n