42

Play 2.0Scalaを使用して REST API を公開するアプリケーションを開発しています。これらの API は、Web、モバイル、またはデスクトップのさまざまなアプリケーションで使用されるため、OAuth プロトコル (OAuth2) が最も適しているようです。

また、最初は Facebook などの外部 OAuth プロバイダーを使用します。

私の質問は、個々の REST 呼び出しを承認するための正確なフローは何ですか? 各呼び出しに対してサーバー側で何を期待する必要がありますか? また、外部プロバイダーに何を確認する必要がありますか?

OAuth1 では、クライアントがすべての署名付きリクエストでトークンを送信したことはわかっていましたが、Oauth2 ではそうではないと思います。トークンが署名されていない場合は信頼されていないので、これはフローではないと思います。

4

7 に答える 7

17

SecureSocial というモジュールを使用できます。

https://github.com/jaliss/securesocial/

これは非常に洗練されており、Play コミュニティの多くの人がこのモジュールを認識/使用しているようです。

認可のために役立つかもしれません。 https://github.com/schaloner/deadbolt-2/

エンド ツー エンドの scala については、 https://github.com/t2v/play20-auth

于 2012-07-13T05:16:41.907 に答える
7

基本的に、標準的な流れは次のとおりです。

  1. リクエストごとに、ID が含まれているかどうか、Cookie (Play! 方言では「セッション」) をチェックインします。
  2. そうでない場合は、プロバイダー (Facebook など) で認証するようにユーザーに依頼します。
  3. OK の場合、プロバイダーは ID を返し、この ID を永続化システム (登録) と現在の Cookie/セッションに保存します。
  4. 次のリクエストで、ID が Cookie/セッションに存在し、永続化システムの既存のユーザーに対応しているかどうかを確認します
  5. 「ログアウト」するには、Cookie/セッションをクリアするだけです

詳細が必要な場合は、お問い合わせください:-)

于 2012-07-15T12:21:42.527 に答える
4

OAuth は認証プロトコルであるため、認証ソリューションを見ている場合、これはそうではない可能性があります。

API のコンシューマーがさまざまなアプリケーションになるという質問です。これにより、2 つのシナリオが発生します。

 1. Where there is no end user involved (grant_type: client_credential)  
 2. Where end-user can consume these APIs on multiple Application (Owned by your Org) (grant_type: implicit/password)
 3. Where end-user can consume these APIs via third Party Applications.(authrization_code)

OAuth エコシステムをサポートするには、鍵管理システムが必要です。に、

  1. アプリのキー/シークレットを生成します。
  2. AccessToken/Refresh_token/authorization_code の生成

エンドポイントに来て、公開する必要があります。

3-Legged OAuth
GET     /authorize  authorize{entry point/ initiate oauth}  
    Sample Call: http://YourAPIService.com/authorize?response_type=code&client_id=GG1IbStzH45ajx9cEeILqjFt&scope=READ&redirect_uri=www.google.com

    GET     /login  login (Call Page for login App, 302 redirected from /authorize)     
Sample Call: http://YourAPIService.com/v1/oauth20/login?response_type=code&client_id=GG1IbStzH45ajx9cEeILqjFt&scope=READ&redirect_uri=www.google.com

    POST    /dologin    consentPage     http://YourAPIService.com/dologin 
    Submit the credential, On success, render the application page 

    POST    /grantpermission    consentSubmission   http://YourAPIService.com/grantpermission
Permission has been granted/declined. Send a 302 to generate authorization_code 

    GET      /code          AuthorizationCode {To generate auth code}
    Sample Call: http://YourAPIService.com/code?client_id=GG1IbStzH45ajx9cEeILqjFt&response_type=code&user_id=user@YourAPIService.com&redirect_uri=www.google.com

    POST    /token  GenerateAccessToken     http://YourAPIService.com/token 
Sample call: http://kohls-test.mars.apigee.net/v1/oauth20/token
Header: Authorization: Basic R0cxSWJTdHpINDVhang5Y0VlSUxxalFj its generated with apps Api Key & Secret.
Payload: 
grant_type=authorization_code&scope=x&redirect_uri=www.google.com&code=abc123

それ以外の場合、最も単純で堅牢なソリューションは http://apigee.comです。

Apigee の既存の OAuth エコシステムを使用できます。

于 2013-04-17T17:33:42.530 に答える
1

自分では試していませんが、tuxdnaモジュールはどうでしょうか。githubリポジトリのように、次のように書かれています:

Play! を使用した OAuth2 サーバー 2.0 フレームワーク

これが役立つことを願っています

于 2015-03-18T13:33:40.073 に答える