28.SpringSecurity-重構社交登陸

前言

以前咱們作瀏覽器社交登陸的時候:

1. 他走的是直接訪問咱們第三方應用Client,走的是一個標準的OAuth2流程

App社交登陸:
1.App架構下已經變了,用戶再也不直接訪問咱們應用,直接訪問的是一個app，用戶直接在app上點擊時候不是直接訪問的咱們應用裏面的請求路徑而是訪問的是服務提供商提供的SDK。這個SDK會引導用戶去完成受權流程。
2.不一樣的服務商,對應的SDK是不同的。而後選擇的受權模式是不同的：一種狀況是走的簡化模式，另外一種狀況是走的標準的受權碼模式。
3.簡化模式:
App的sdk將用戶導向認證服務器時候,認證服務器返回的不是受權碼,直接是accessToken和openId。 實際上這個時候app已經知道用戶的微信openId了,這個時候App其實能夠用openId和accessToken直接去資源服務器獲取用戶的信息。可是他不能拿着openId和accessToken去訪問咱們本身後臺提供的服務(咱們在這裏是第三方應用Client);由於此openId和accessToken是服務提供商發給用戶的，用戶若是須要訪問咱們的應用服務,那麼就須要咱們發送給他的令牌。這種狀況下,咱們應用須要提供一個後端服務。用他的openId來換取咱們自個應用的令牌;也就是咱們須要用openId來登陸。用戶給一個正確的openId,咱們應用根據這個openId查詢出用戶信息，生成一個令牌給用戶。要實現這種功能，其實和短信登陸作的事情是同樣的。只不過業務邏輯裏面驗證的不是短信驗證碼,而是一個openId,根據這個openId去查詢用戶信息。若是存在的話就返回令牌給用戶,若是不存在的話就返回錯誤。

內容