Backbone.js フロント エンドを使用して、モノリシック Rails アプリを純粋な JSON API にリファクタリングしています。近い将来、他のスマートフォン アプリのフロントエンドがこれに続く予定であり、API を一般に公開する可能性が社内で議論されています。
そのため、最初のラウンドで適切に作業を行い、REST API を OAuth 2.0 で保護して、社内で構築したものを含め、その上に構築されたすべてのアプリが「単なる別の OAuth クライアント」になるようにしようと考えました。これにより、レート制限、キーの取り消し、無料で操作できるリソースの制限など、通常の機能も提供されます。
これまでのところ、Doorkeeper gem に関するRailscasts のエピソード(警告、これはプロのエピソードです) に従って、独自の API を保護し、ユーザー向けの Web アプリをクライアントとして登録しました。
ここで興味深いのは、元のアプリでは、ユーザーが Omniauth gem を介して Facebook、Google、Twitter などからサインインできることです。私が理解しているように、OAuth はユーザー認証ではなく、クライアントの承認に関係しているため、既にある OmniAuth フローが引き続き必要になります。
しかし：
- 「Omniauthing」コントローラーは、API または Web クライアントのどこに配置する必要がありますか?
- ユーザーを認証するための「Omniauthビット」は、「OAuthビット」にどのように接続する必要がありますか?
更新: クライアントは、単なるバックボーン アプリの場合もあれば、独自の DB を持たないが、ActiveResource を使用してバックボーン アプリと API の間を仲介する「薄い Rails Web サイト ラッパー」とツイン化されたバックボーン アプリの場合もあります。「秘密を守れるクライアント」に対応できるメリットがあります。このシナリオでは、"Omniauthing" コントローラーは、必要に応じて Rails クライアント アプリに配置できます。
同様のSO の質問では、Facebook のみでのログインについて議論されましたが、認証サーバーは 1 つ (Facebook) のみであるべきであるという答えは明らかでしたが、ユーザー認証の結果をリソース サーバーに供給することについては何も述べていませんでした。