4

私は残りの API を使用してアプリケーションの作業を開始しようとしていますが、敏捷性を使用したいと考えています。残念ながら、このアイデアには 1 つの問題があります。通常のユーザーに oAuth による認証を許可する方法について、信頼できる情報源が見つかりません。

angular アプリとネイティブ モバイル アプリへのアクセスを提供する必要があります (将来的には、サード パーティの Web アプリに対応する可能性があります)。私が見つけたすべてのリソースは、このアプリケーションを使用する特定のユーザーではなく、特定のクライアント アプリケーションに対して API へのアクセスを許可することに関するものです。2 つの異なる認証方法を実装したくないので、この問題を機敏に解決する方法があれば、それは素晴らしいことです。

これにアプローチする方法について何か提案はありますか? すべての登録ユーザーのクライアント ID とシークレットを生成できることはわかっていますが、これは少しくだらない解決策であり、ユーザー情報を格納するためのデータベース スキーマが既に用意されています。

4

1 に答える 1

8

おそらく探しているのは、「パスワード」許可タイプです。このシナリオでは、ユーザーとそのパスワードを登録する方法と、一種の「ログイン」画面があります。このログイン画面では、次の情報が送信されます。

  • ユーザー名
  • パスワード
  • client_id -- これは、アプリケーションの OAuth2 クライアント ID (ユーザー ID ではありません!) になります。
  • "grant_type": "パスワード"

このシナリオでは client_secret を提供していないことに注意してください! ユーザー資格情報のシナリオの場合、ユーザーの資格情報が検証された後、サーバーは client_id がこの付与タイプをサポートしていることを確認します。

ユーザーが正常な資格情報を提供すると、OAuth2 エンドポイントはトークン、TTL、および refresh_token を返します (TTL が期限切れになる前に送信すると、新しいトークンのセットが提供されます)。

ここから、「Authorization: Bearer」という Authorization ヘッダーでトークンを送信します。その後、Apigility は各リクエストでこれを取得し、トークンを検証します。

検証では、ID の一部としてユーザー名も返されます。これは、後でユーザー固有の ACL アサーションを実行するために、ZF\Mvc\Identity をクエリしてユーザーを取得できることを意味します。

さらに指示が必要な場合は、メーリング リスト ( http://bit.ly/apigility-users ) で私を尋ねてください。

于 2014-05-21T13:08:54.817 に答える