What are the differences and connections between OAuth and SSO, rest?

When it comes to oauth, many people naturally think of SSO and others think of rest. In fact, OAuth does not have a deep relationship with SSO and rest, and they have different scenarios for each. Next, let's look at the difference between them and what the connection is.

The difference between OAuth and SSO.

OAuth is an authorization protocol that provides a secure, open, and simple standard for the authorization of user resources. OAuth 2.0 provides client developers with a specific authorization process for developing Web applications, desktop-side applications, mobile applications and living room devices.

SSO is a multi-application system in which users can access all trusted applications with only one login.

In layman's words, OAuth is a simple authorization scheme to solve the different products of different companies, usually these authorized services are provided by the big customer's website, such as QQ, Sina Weibo, Renren etc. Customers who use these services may be large customer sites or small customer sites. The advantage of using OAuth authorization is that you can reduce or avoid user churn caused by users being lazy when they provide certain services to users.

SSO typically deals with access issues between different applications of a company. If the enterprise application has a lot of business subsystems, just log in a system, you can achieve different subsystems of the jump, and avoid landing operations.

OAuth is different from SSO's scenario, although you can use OAuth to implement SSO, but this is not recommended. However, if SSO and OAuth are combined, it is theoretically possible to get through the various applications of various companies, but the reality is often brutal.

The relationship between OAuth and rest.

When it comes to the security of rest, many people tend to associate with OAuth to solve this problem. In fact, rest and OAuth are vastly different.

OAuth provides a specification for Web site (System) users to authorize third-party applications (websites, systems) to access their own privacy data in the site (System).

The early idea of rest is that "every different sub-resource has an absolutely unique and non-duplicate URI address." It is just a URI resource and stateless, so rest is not suitable for applications that require authorization. On the contrary, when using OAuth authorization, the rest API is typically used to complete authorization operations.