中小企業のためのOAuth2過剰
私は現在、Webアプリケーション、iPhoneアプリ、およびAndroidアプリ）と対話するAPIを作成中です。APIはかなりシンプルで、パイロットとその可用性を扱います。
私はAPIとクライアント側アプリケーションを作成しているので、ユーザー名/パスワードがクライアントアプリケーションを通過するかどうかは本当に気にしないので、OAuth2はこれに対して過剰であるように思えます。
「Admin」、「Supervisor」、「User」などの異なるuser_rolesが必要で、これに基づいてAPI呼び出しへのアクセスを制限します。
これについて簡単な方法はありますか？ SSL経由の基本認証？
SSLを介した基本認証の問題は、すべてのAPI要求で可逆的にエンコードされたユーザー資格情報を渡すことに依存していることです。これはセキュリティ上の問題です。すべてのリクエストでユーザーに認証情報を送信させるつもりでない限り、ユーザー認証情報をクライアントデバイスまたはブラウザに何らかの方法で保存する必要があります（ブラウザは通常、基本認証認証情報をキャッシュして保存しますクリアするのが難しい方法）。ユーザーの資格情報が保存されると、他の誰かがそれらにアクセスする余地が残ります。
ログイン時に付与され、有効期限があり、いつでも取り消すことができる何らかのトークンを使用する方がはるかに優れています。誰かがトークンにアクセスしたとしても、ユーザーが同じパスワードを使用しているすべてのシステムではなく、トークンにアクセスできるので、トークンはより安全に使用できます。
OAuth2はアプリにとってはやり過ぎかもしれませんが、優れたセキュリティプラクティスを使用せざるを得ず、多くの人がしばらくの間それを使用しているため、セキュリティプロトコルとしてかなり成熟しているため、これは良い選択かもしれません。思いついたプロトコルには、考えていなかったセキュリティホールが含まれている可能性があります。申し訳ありませんが安全である方が良いです。
そうです、OAuth2はこの特定のケースではやりすぎです。コメントにもかかわらず、プロジェクト全体に不必要な複雑さを追加します。とはいえ、OAuth2は認証プロトコルではないことを忘れないでください。そのため、今のところ、このままにする理由はもう1つあります。とにかく、これを見てください 記事 自分の結論を得て、それがあなたに適しているかどうかを判断してください。
OAuth2の主な目的は、資格情報を共有する必要なしにデータを共有することをさまざまなアプリケーションプロバイダーに許可することです。私はそれがあなたのケースではないと思います（まだ）。
例えば：
IauthoriseInstagramを使用してFacebookの壁に写真を公開します。そして、私はauthoriseFacebookで私のデータと私の連絡先をInstagramと共有します。
それでおしまい。ただし、多くの開発では、OAuth2を専用のセキュリティサーバー（承認と認証）として実装しています。それは正しいことでも間違ったことでもありません。それは彼らのニーズに最もよく応えるソリューションにすぎません。
他の人がやるからといって何かを実装するべきではありません1。そうすると、おそらく不適切なソリューションになってしまうでしょう。セキュリティにおいて最も重要な懸念の1つは適合性です。セキュリティ対策が不適切だと、予期しないセキュリティホールが発生する可能性があります。
基本認証に関する問題（ とりわけ ）は2つあります。
弱いエンコーディング （base 64）および暗号化された資格情報の予測可能な形式。
クライアント側の永続性。
ブラウザは、認証情報を何度も要求しないように、基本認証ヘッダーを保存します。これは非同期呼び出し（Ajax）では発生しません。そのため、資格情報をクライアント側のどこかに保存する必要があります。これにより、LocalStorageとCookieが表示されます。どちらも [〜＃〜] xss [〜＃〜] 攻撃に敏感です。
この脆弱性は、何を保存するかに関係なく存在しますが、選択する必要がある場合は、十分に暗号化されたトークンを公開することを選択する必要があります。これは、基本認証の場合とは異なります。
最初の（暗号化されたトークン）は私のアカウントを脆弱にするかもしれませんが、2番目（base 64エンコードされた資格情報）は完全に家の鍵を与えています。
それで、何をしますか？ログインプロセスを実装する必要があり、認証と承認のための確かなトークンベースのメカニズムが必要なため、 [〜＃〜] jwt [〜＃〜] がおそらく最良の選択です。
シンプルで、十分に文書化されており、コミュニティによって広くサポートされています。そして全体として、それは適切です。
この時点で、あなたは興味があるかもしれません OWASP REST Security Cheat Sheet 。セキュリティはすべて認識と適切な予防策に関するものです。2
注：OAuth2とJWTは相互に排他的ではありません。両方を組み合わせることができます。最後に、セキュリティの脅威はWebアプリケーションとモバイルアプリケーションで異なるため、それぞれのセキュリティ対策も異なります。そのため、適合性が重要です。
1：これは、ホイールを再発明する必要があるという意味ではありません。地獄！ OAuth2が必要な場合はOAuth2を使用します。それでおしまい2：OAuth2とJWTのどちらを実装しても、SSLは必須です
やり過ぎだとは思いません。クライアントとサーバーの両方に膨大な数のライブラリがあります。これは、今日ほとんどすべてで使用されている標準プロトコルです。やり過ぎだと思うので、この標準を無視するのはばかげています。代わりに、それが何であるか、および標準の幅を理解するのに少し時間を費やす必要があります。きっとあなたのユースケースに対応できると思います。