4

特に client_id と client_secret の送信を使用して oAuth2rize と Passport.js を使用してリソース オーナーのパスワード フローを実装する方法を理解する上でいくつかの問題が発生しているため、クライアントでいくつかのチェックを実行して、このエンド ポイントに何かが入ってくることを確認できます (/特定の「パスワード」許可タイプを使用するトークン) は、具体的には公式アプリケーションであり、ID とシークレットに基づくものではありません。

ソリューションを構築するときにトークンを取り戻すことができますが、それはクライアントで検証を行う前です。パスワード交換戦略に渡されたクライアント変数 (エンドポイントに投稿) にアクセスしようとすると、ドキュメントに基づいて期待されているが、ここで達成する必要があるものではないユーザー資格情報 (ユーザー名、パスワード) を受け取ります。

実際のクライアント資格情報を取得する方法を理解するのに途方に暮れています。パスワード関数のソースコードで、req['user'] へのデフォルトの割り当てをオーバーライドする追加オプションを提供できることがわかりますが、それはいくつか提供する必要があることを意味しますか? req オブジェクトに追加するコードの種類は?

いくつかの統合テストをセットアップしました。これがエンドポイントを呼び出す方法です (SuperTest を使用):

                request('http://localhost:43862')
                    .post('/oauth/token')
                    .type('form')
                    .send({ grant_type: 'password' })
                    .send({ client_id: 'goodClient' })
                    .send({ client_secret: 'asecret' })
                    .send({ username: 'good@user.com' })
                    .send({ password: 'goodpassword' })
                    .expect(200, done);

どういうわけか、私はこれを完全に考えすぎているようですが、何らかの理由で完全に困惑しています....

4

1 に答える 1

4

予想通り、ClientPasswordStrategy の代わりにローカル ストラテジーを使用し、トークンを発行する前にパスワード交換内でユーザー検証を行っていたのは、理解の問題でした。

現在、ClientPasswordStrategy を使用しており、exchange.password 関数内でユーザー API を呼び出して内部呼び出しを行い、ユーザー資格情報を検証し、OK の場合はトークンを発行しています。

passport.use(new ClientPasswordStrategy(

function(clientId, clientSecret, next){

    Client.verify(clientId, clientSecret, function(err, verified){

        if(!verified){
            return next(null, false);
        }

        next(null, clientId);
    });

}
));

passport.use(new BearerStrategy(
function(token, next) {

    Token.getByToken(token, function(err, tokenObj){

        if(err)
            return next(err);

        if(!tokenObj)
            return next(null, false);

        User.getByUsername(tokenObj.username, function(err, user){

            return next(null, user, { scope: 'all' });
        });
    });
}
));
于 2013-05-21T14:35:25.107 に答える