OAuth 2ファーストパーティSPAの暗黙の付与タイプ-最も安全で賢明な方法
私の目的は、ステートレスAPIを保護し、登録済みのファーストパーティクライアント（SPA）だけがリソースを消費できるようにすることです。私のシナリオでは、サードパーティのクライアントは存在しません。
私は知っていますOauth 2暗黙の許可タイプの承認がパブリッククライアント（私の状況では、SPA）に推奨されます。私はそれについて多くのことを読みましたが、いくつかのポイントを理解できなかったので、私はあなたの助けを求めています：
Oauth 2暗黙の許可タイプを使用するのがこれを達成するための最良の方法だと思いますか？クライアント資格情報の許可タイプはクライアントシークレットの機密性を維持できないため、SPAにとって安全ではありません。だから私は暗黙の付与タイプでOauth 2と一緒に行くべきですか？
Oauth 2の場合、自動承認で暗黙の付与タイプを使用できるため、ユーザーの同意を得る必要はもうありません。ただし、私のSPAをファーストパーティのアプリと考えるため、ユーザーがどこにでもリダイレクトしてログインしてSPAページに戻ることを望まない。
私のAPIに対してhttp基本認証を有効にすることは安全で賢明だと思いますか？そうすれば、私のファーストパーティのアプリがユーザーの資格情報を取得して認証ヘッダーに追加し、SSL/TLSチャネル経由で認証サーバーに送信して認証とアクセストークンを取得しますか？
それが適切でない場合、この目標を達成するために何をお勧めしますか？
また、認証されていないユーザーが私のSPAのリソースを消費するようにします。これらのリソースを任意のクライアントおよびユーザーに対して公開する（実際には好まない）か、SPAがダミーの匿名ユーザーで認証および承認されて、匿名APIでアクセストークンを取得し、パブリックAPIリソースを消費することを期待する必要があります。
ウィキペディアのようなWebサイトの場合、アクセストークンの有効期限はどのくらいかかりますか？
有効期限が切れた場合、どの方法を使用すればよいですか？ OAuth 2暗黙の許可タイプに更新トークンがありません。ユーザーに資格情報をもう一度入力するように要求するか（これはユーザーフレンドリーではありません）、または資格情報をストレージに保存して、許可サーバーは、新しいアクセストークンを取得するためにサイレントモードで実行しますか？
あなたの場合、OAuth 2は意味をなさないと思います。これはサードパーティのクライアントを処理するように設計されており、最初のシングルが1つしかない場合は、さらに複雑になる可能性がありますパーティのクライアント。
ユーザーセキュリティの場合：
- あなたが何をしても、ウェブベースのアプリは、ユーザーが自分のウェブページをユーザー名/パスワードで信頼する必要があるアプリです。このため、他の何らかの理由でOAuth 2.を使用しない限り、ユーザー名+パスワード認証を直接スキップして、OAuth 2をスキップすることをお勧めします。
- 公開されているリソースの場合、認証なしでアクセスを許可することで問題ありません。
APIをSPAでのみ使用できるように保護するの場合：
- これはユーザーのサインインとはまったく別の問題であり、アクセストークンを取得する方法によって回避されないようにすることをお勧めします。たとえば、多くのSPAは簡単に変更/逆コンパイル/スプーフィングできます。