OAuth 2.0 for REST Webサービス

Question

私は既存のアプリケーションのRESTレイヤーを実装しています。私は自分のユーザーIDとパスワードをデータベースに格納していると私は私のRESTサービスを呼び出している間、これらの資格情報を認証したいと思います。これはスタンドアロンアプリケーションであることに注意してください。

調査の結果、私は2つの方法を考え出しました。

• このアプローチでは、 ユーザーIDとパスワードが渡されたことが、中間の攻撃でManによって改ざんされていないことが確認されます。
• 認証トークン（JWT）の使用 - ユーザーは最初にユーザーID を渡し、パスワードとサーバーは認証トークンを返します。ユーザー には、その後の 要求に使用できる認証トークンがあります。
• OAuth 2.0の使用 - 私はこのアプローチでは非常に混乱しています。ドキュメントや仕様を読んだ後、私は自分のアプリケーション がスタンドアロンであることから、私は認証サーバー、リソースを実装する必要があることがわかった サーバーなど私はここでのOAuthを実装するように求めていますが、私は確信していない

このシナリオではOAuthが必要です。私はちょうどJWT（トークン）を実装する方向に傾いています

OAuthは本当にこのシナリオで必須ですか？ OAuthについて私が理解していることは、あなたがすでにFacebook/Googleのようなサービスを持っているときに使用されていることです。

私の考えの列が正しいかどうか、この場合OAuth 2.0が必要な場合は、誰かが確認できますか？

Answer 1

OAuth 2.0の第1の目標は、ユーザーの資格情報（通常はユーザー名/パスワード）を公開せずに、サードパーティの認証プロバイダ（Google、Facebookなど）を介してクライアントアプリケーションを使用することをユーザーに許可することです。クライアント。

あなたのケースでは、ユーザーが自分のデータベースの認証情報を使用してシステムに認証する場合、OAuth 2.0を実装しても実質的な価値はありません。

OAuth 2.0仕様では、ユーザが資格情報を送信し、アクセストークン（必要に応じてJWTになる可能性があります）を返すという、従来のユースケースを対象とした"Resource Owner Password Credentials grant"を定義しています。管理やマーケティングの観点からは、リソースオーナーパスワード資格認定を実装し、アプリケーションが「RFC6749で定義されているOAuth2のサブセットに準拠している」ことを合法的に述べることができます。