What is the relationship between Spring social and oauth2 protocol?

Question

I read some stuff about oauth2 protocol and its concepts like:

• resource owner
• resource server
• authorization server
• grant types and etc..

Does spring-social use oauth2 protocol?

For example if I want to have social login with facebook, what is the role of facebook, appTest,... in oauth2 terms?

UPDATE

After a considerable amount of searching i found https://www.credera.com/blog/ecommerce/spring-social-alternative-oauth.

but i'm still confused about oauth2 concepts authorization server, resource server and ... in spring social.

Answer 1

From the link in question:

Oauth specification was first released in 2007, OAuth has been the standard method of authentication for software-as-a-service providers. OAuth provides the means for a client website to access user information from a third party on behalf of the user, without requiring the user to provide their login details. Unfortunately for developers, implementing the OAuth handshake with various providers can be quite tedious

Spring Social, a project that drastically simplifies the process of creating and managing third party provider connections. The goals of the project are to abstract the specific implementation details of each service to provide developers with a simple method of getting each service’s API in a strongly-typed Java binding, and to cleanly organize stored connections so that they can be associated with the application’s local users.

There are numerous benefits to using Spring Social instead of plain OAuth. Spring Social handles all of the variants of the OAuth protocol that are out on the web, and with its support of provider specific modules, anyone can adapt it to connect to any OAuth enabled provider. The framework provides built in connection storage and management, and provides users with a Java-consumable API specifically tailored for the service they are using.

In addition, though Spring Social currently relies on OAuth, it is not dependent on the protocol. Since authorization protocols are completely abstracted from any exposed connection details, no refactoring should be required when providers inevitably change their authorization strategy.