ここ数週間、私は認証と、RESTful サービス、より具体的には asp.net Web API を介してユーザーを保護および認証するためのさまざまな方法について手に入れることができるものは何でも読んでいます。これは実際に http 認証に飛び込むのは初めてで、読めば読むほど混乱します。
私のプロジェクトのアプリケーション インフラストラクチャについて詳しく説明しましょう...
Web アプリケーションのデータ アクセス レイヤーとして機能する RESTful サービスを構築しています。アプリケーション自体は、ほぼ AngularJS から構築された SPA になります。ユーザー ログインと CRUD 操作はすべて API を介して処理され、HTTPS ではなく http で行われます。
私はさまざまな記事や例をたくさん読んできましたが、自分の目標にとって意味のある方向性があると思います。Amazon Web Services が認証を行う方法に似たアプローチを採用したいと考えています。The Buzz Media には、高レベルで認証を行う方法を具体的に説明している優れた記事があります。また、記事の高レベルの説明 (具体的にはサーバー コードのセクション) によく似た例も見つけました。
でも、迷っているところもあるし…
- ユーザーがクライアント (私の場合は Angular) を介してログインすると、クライアントはユーザーのパスワードを使用してハッシュを作成します。ハッシュには、apikey と、api とクライアントだけが知っているシークレットが含まれます。ログイン時にクライアントはシークレットをどのように取得しますか? シークレットを取得するためにログインする前に、最初にリクエストを作成する必要があるようです。次に、ハッシュを作成し、ユーザーを認証するために別のリクエストを送信しますか? コード例は非常に役立ちます。
- DelegatingHandler を使用するか、各コントローラーを装飾するカスタム Attrubite を作成しますか? なんで？
- ユーザーが認証されたと見なされたら、そのユーザーのデータベースに保存され、応答で返される nonce を作成します。クライアントは、次のリクエストでこのノンスを使用します。上記のサーバー コード例のリンクでは、nonce が生成されますが、クライアントに送り返されることはありません。この例ではカスタム属性を使用していますが、応答でこのナンスがクライアントに返される方法について混乱していますか? 繰り返しますが、コード例は非常に役立ちます。
- そこから先は、すべてのリクエストでクライアントが apikey、nonce、およびデータをハッシュし、API サービスが応答で新しい nonce を送り返すだけですか? 何か不足していますか？