春のブートJavaアプリケーションを使用して休憩Apiを確保する最善の方法は何ですか？

Question

私はRest APIを安全にしたいのですが、これはRest APIを確保する最良の方法ですか？リクエストヘッダーで認証するためにユーザー名とパスワードを使用したいと思います。私はOAuth2とJWTトークンと混同しています。可能であれば、私にサンプルを提供してください。

Answer 1

このlinkをご覧ください。 username：passwordとOAuthの違いについて説明します。時間の大半は、それは追加のライブラリなしで実装することができますので、TLS/W

基本API認証が

基本API認証は、実装するの3のが最も簡単です。基本認証を実装するために必要なものは、通常、標準のフレームワークまたは言語ライブラリに含まれています。基本認証の問題は、それが「基本的な」ものであり、共通プロトコルの最も低いセキュリティオプションを提供することです。このプロトコルを使用するための高度なオプションはありませんので、Base64でエンコードされたユーザー名とパスワードを送信するだけです。ユーザー名とパスワードの組み合わせを他の方法で簡単に解読できるため、基本認証はTLS（以前のSSL）暗号化なしでは使用しないでください。

OAuth1.0a

のOAuth 1.0aのは、3つの共通のプロトコルの最も安全です。 OAuth1は、広く使用され、テストされ、安全な署名ベースのプロトコルです。このプロトコルは、トークン・シークレット、ノンス、およびその他の要求ベースの情報を組み合わせた暗号署名（通常はHMAC-SHA1）値を使用します。 OAuth 1の大きなメリットは、トークンシークレットを直接渡すことがないことです。これにより、通過中に誰かがパスワードを見る可能性が完全に排除されます。これは、SSLなしで安全に使用できる3つのプロトコルの唯一のものです（ただし、転送されるデータが機密である場合はSSLを使用する必要があります）。しかし、このセキュリティレベルには価格が付随しています。シグネチャの生成と検証は複雑なプロセスになる可能性があります。厳密な一連のステップで特定のハッシュアルゴリズムを使用する必要があります。しかし、すべての主要なプログラミング言語があなたのためにこれを処理するライブラリを持っているので、この複雑さはしばしば問題になりません。

のOAuth2

のOAuth2はOAuth1の進化のように聞こえるが、実際にそれが複雑さを軽減しようとする認証に完全に別のテイクです。 OAuth2の現在の仕様では署名が削除されるため、暗号アルゴリズムを使用して署名を作成、生成、検証する必要はなくなりました。すべての暗号化はTLSによって処理されます。これは必須です。 OAuth1aライブラリと同数のOAuth2ライブラリが存在しないため、このプロトコルをREST APIセキュリティに活用するのは難しいかもしれません。

OAuth2標準の筆頭著者と編集者はこの有益な投稿を辞任しました。仕様委員会のこの不安定さと、OAuth2のデフォルト設定がOAuth1よりも安全でないため（デジタル署名なしで、 tコンテンツが改ざんされているかどうかを確認する）、OAuth1よりOAuth1を使用して機密データアプリケーションを推奨します。 OAuth2は、ソーシャルネットワークのように、あまり敏感でない環境でも意味をなさないでしょう。あなたは本当に、本当にあなたが何をしているか知っていて、完全に暗号化、デジタル署名のすべての複雑さを理解していない限り

カスタムプロトコル

カスタムAPIの認証プロトコルは避け​​るべきです。ほとんどの組織はこの専門知識を持っていないため、OAuth1.0aを堅実な選択肢として推奨します。

あなたは、この潜在的に危険な道を取って喜んでいる場合であっても、それを回避するために、別の理由がある：それは習慣、あなたは簡単にそれを使用することができるようになります以外のものですので。 REST API呼び出し元（Java、Ruby、PHP、Pythonなど）に与えることができるクライアントライブラリをサポートしたい場合は、カスタム認証プロトコルのみを使用して、ユーザがほとんどまたはまったくこのプロトコルを使用することができます。それ以外の場合、APIは無視されます。

私たちは何を選択しましたか？ Stormpathでは、カスタム認証プロトコルを使用しています。 OAuth1と非常によく似ていますが、多くの拡張機能があります（たとえば、OAuth1とは異なり、Stormpathのスキームは、ボディを改ざんできないように署名を計算する際にリクエスト本体を使用します。しかし、このアルゴリズムは、このアルゴリズムを実装しているSDKを使用しているクライアントにのみ役立ちます。また、SDKを使用できないクライアント用の他の一般的なプロトコルもサポートしています。

なぜユーザー名/パスワード認証対を使用するAPIキー

一つ我々が使用する他の技術ではなく、伝統的なユーザ名/パスワード認証のAPIキーが生成されます。その決定は、私たちのブログ上で十分に文書であるが、それはAPIのセキュリティのためにも非常に重要ですので、ここではAPIキーにクリフノートです：鍵/秘密が、通常はそのランダムな文字の長いシリーズです

エントロピー

API推測するのは難しいです。ユーザー名/パスワードは通常、長さがはるかに短く、一般的な言葉を使用し、一般的に安全ではなく、ブルートフォースや辞書攻撃の対象となります。

パスワードリセットの問題

パスワードは頻繁にリセットされます。 API認証スキームの一部としてパスワードを使用すると、パスワードが変更されるたびにAPIアクセスが失敗します。

スピード

ベスト・プラクティスは、潜在的なデータ侵害を制限するために、データベースのパスワードを暗号化するために言います。これにより、ユーザーの認証時に各要求のオーバーヘッドが増加します。ユニークなAPIキー認証はハッシュステップをスキップして呼び出しをスピードアップします。

したがって、実装に最も適したものを決定してください。