Share This Article
OAuth 2.0 is a framework that’s shaping how web applications communicate with one another and define authorization among them. It’s just one in a suite of modern protocols that IT admins should be aware of, and here we’ll cover how it can be part of your identity and access management (IAM) strategy.
OAuth Defined
OAuth 2.0 is an authorization framework released in 2012. It delegates authorization to a third-party authorization server via access tokens, rather than passing credentials between a client and the resource server it’s accessing.
The tokens can use either XML documents or JavaScript Object Notation (JSON). In essence, OAuth 2.0 outlines “authorization flows for web applications, desktop applications, mobile phones, and living room devices.”
OAuth 2.0 can be combined with OpenID Connect for authentication needs, but it is not compatible with its predecessor, OAuth 1.0
Benefits of OAuth
Major consumer players in the industry utilize OAuth 2.0 (e.g. Google, Facebook, Twitter, et al). Google APIs use it for authentication and authorization, for example.
OAuth can also be used to define the scope 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.
It’s also an open standard geared toward developer simplicity. Although it’s used for authorization flows to web applications, OAuth differs from another major protocol used to authenticate to web applications, SAML.
Difference between OAuth and SAML
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.
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 — 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.
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.
Although the protocols have different uses, they can be used in conjunction in a comprehensive identity and access management solution — including in tight integrations between a cloud directory service and productivity suites like G Suite and Office 365TM.
OAuth in Identity and Access Management
OAuth is just one of many in a suite of modern protocols 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.
Ideally, a central identity provider would have the capability to leverage all those protocols as it connects users to systems, applications, files, and networks — 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.
Learn more about leveraging all these protocols, including OAuth, from a cloud identity provider.
