oauth2策略與紅寶石上的許多客戶端，有一個API的軌道上

Question

我一直在研究oauth2一段時間了，還沒有拿出完美的解決方案，並希望看看是否有其他人已經做到了這一點。目前我在一個代碼庫中有兩個應用程序。這些應用程序共享的唯一內容是身份驗證我期望做的是爲oauth2服務器創建第三個應用程序。然後我想將現有的應用程序分成兩個應用程序。試圖追蹤Google如何處理他們的oauth資料。所以這些域名就是這樣的。

• http://accounts.domain.com
• http://app1.domain.com

我發現了一些好的信息，關於守門人，並制定這兩個職位。目前我正在使用設計，以便使這部分更容易。

• https://dev.mikamai.com/2015/02/11/oauth2-on-rails/
• https://dev.mikamai.com/2015/03/02/oauth2-on-rails-the-client-application/

所以每個應用程序APP1和APP2將有API的是，使用將需要對被認證。

所以我有以下問題。

1. 如果APP1需要與帳戶子域，以驗證這是否從一個API角度來看，我需要調用每個請求的oauth2服務器應用程序是什麼意思？這似乎是一個很大的開銷。 Google是這麼做的，或者他們有一些竅門？

2. app1和app2每個都會對自己的會話超時負責嗎？如果app1會話有效，但用戶通過轉至auth2服務器應用程序直接刪除其帳戶，會發生什麼情況？

3. 如果app1和app2負責會話，那麼他們是否也想回撥到賬戶oauth2服務器來驗證用戶是否仍然存在？

我試圖刷新所有的這一點，並沒有發現如何當OAuth用戶端實際上是API的加上他們的網絡應用程序太多這樣的工作一個很好的例子。也許我也在想它，並且每個API請求的額外呼叫都是這樣。

任何幫助或教程，將不勝感激。

Answer 1

The OAuth 2.0 Authorization Framework提供了五種批技術：

• 授權代碼授予
• 隱性補助
• 資源所有者憑證授予
• 客戶端證書授予
• 刷新代金券授予

我是我們正在討論關於Client credentials grant（我認爲谷歌普遍使用它）。

讓我們試着去了解這個流程圖：

所以，here在步驟[E]：

步驟（C）和（d）重複，直到訪問令牌到期。如果 客戶端知道訪問令牌已過期，則跳至步驟（G）; 否則，它會發出另一個受保護的資源請求。

這意味着它實際上不會在每個請求上打Authorization Server。當client發現令牌已過期時，它僅碰到授權服務器。所以，如果我們自己刪除，它會使令牌過期！

也許這些文檔可以幫助你更多：

1. https://tools.ietf.org/html/rfc6749
2. https://alexbilbie.com/guide-to-oauth-2-grants/

乾杯！