web-dev-qa-db-ja.com

Cookie + CSRFトークンとOAuthネイティブモバイルアプリのトークン

ASP.NET WebApiエンドポイントを利用した既存の単一ページWebアプリケーションがあります。これらのエンドポイントは、SimpleMembershipとフォーム認証を利用して、承認と認証を処理します。

    [System.Web.Http.HttpPost]
    [Route("api/login")]
    [System.Web.Http.AllowAnonymous]
    public HttpResponseMessage LogIn(LoginModel model) {
        if (!WebSecurity.UserExists(model.Username))
            return Request.CreateResponse(HttpStatusCode.OK, new ApiResponseDto() { Success = false, Error = "Email or Password is incorrect." });
        if (_userService.LoginWork(model.Username) && WebSecurity.Login(model.Username, model.Password, persistCookie: true)) {
            return Request.CreateResponse(HttpStatusCode.OK, new ApiResponseDto() { Data = true });
        }
        LogOut();
        return Request.CreateResponse(HttpStatusCode.OK, new ApiResponseDto() { Success = false, Error = "Login Failed" });
    }

現在、ネイティブiOSアプリを開発中です。簡単にするために、これらのAPIエンドポイントを再利用したいと考えています。これを行うために、ネイティブアプリケーションとWebアプリケーションの両方からの認証を処理するために CSRFトークン とCookieを使用しています。

物事をシンプルに保ち、モバイルをサポートするためだけに〜100のAPIエンドポイントを書き直さないというアイデアが好きですが、セキュリティに関して妥協する必要がある場合はそうではありません。このソリューションは、純粋なOAuth2トークンベースの実装の標準実装と同じくらい「安全」ですか？そうでない場合、なぜですか？

authenticationoauthcsrf.net
2
SB2055

確かに、それはなぜでしょうか？ OAuthの多くのユースケースに含まれている（多くの）柔軟性が失われるだけです。特に、自分のアプリのみに関心があり、他のユーザーへのアクセスの委任やユーザーが他のIDプロバイダーにログインすることを許可しないことに関心がある場合は、この設定で問題ありません。つまり、将来アップグレードする場合は、「純粋なOAuth」ではなくOpenID Connectにアップグレードしてください。

いくつかの注意：

  • nativeアプリにはCookieが存在しないため、認証トークン（通常はCookieに含める）をデバイスのローカルストレージに保存する必要があります。そのため、「set-cookie」コマンドをキャッチし、その値をローカルデバイスストレージに保存する、ある種の「トランスレータ」がアプリに必要になる場合があります。同様に、逆も同様です。
  • CSRF攻撃は実際のnativeアプリには存在しません。ただし、ブラウザとアプリの両方に同じエンドポイントを使用する場合は、それらを引き続き使用する必要があります。
  • HTTPS（および場合によってはHSTSとHPKP）を使用して、トランスポート中にトークンを保護します。
2
Michael