タグ付けされた質問 「https」

3
REST APIセキュリティストアドトークンvs JWT vs OAuth
モバイルアプリケーションとAPIの量は日々増加しているため、REST APIを保護するための最適なセキュリティソリューションを探しています。 私はさまざまな認証方法を試しましたが、まだいくつかの誤解があるため、より経験豊富な誰かのアドバイスが必要です。 このすべてを理解する方法を教えてください。何か間違って理解した場合は、お知らせください。 REST APIが一般にWEBと同様にステートレスである限り、各リクエスト(cookies、token ....)で認証データを送信する必要があります。ユーザーを認証するために広く使用されている3つのメカニズムを知っています HTTPSを使用したトークン。私はこのアプローチを何度も使用しましたが、HTTPSで十分です。ユーザーが正しいパスワードとログインを提供すると、応答としてトークンを受け取り、それを以降のリクエストに使用します。トークンはサーバーによって生成され、保存されます。たとえば、ユーザー情報が保存される別のテーブルまたは同じテーブルに保存されます。そのため、各リクエストサーバーで、ユーザーがトークンを持っているかどうかを確認します。トークンがデータベース内と同じである場合。すべてが非常に簡単です。 JWTトークン。このトークンは自己記述的であり、トークン自体に関するすべての必要な情報が含まれています。このトークンは秘密キーワードを使用してサーバーによって生成(署名)されるため、ユーザーは有効期限やその他の要求などを変更できません。これも明らかです。しかし、個人的には、トークンを無効にする方法の1つの大きな問題です。 OAuth 2.サーバーとクライアント間で直接通信が確立される場合、このアプローチを使用する必要がある理由がわかりません。私の知る限り、OAuthサーバーは、他のアプリケーションがパスワードとログインを保存せずにユーザー情報にアクセスできるように、制限されたスコープでトークンを発行するために使用されます。これは、ユーザーが何らかのページでサインアップしたい場合、ソーシャルネットワークにとって優れたソリューションです。サーバーは、たとえばtwitterやfacebookからユーザー情報を取得する許可を要求し、登録フィールドにユーザーデータなどを入力できます。 オンラインストアのモバイルクライアントを検討してください。 最初の質問は、最初のタイプのトークンよりもJWTを好むべきですか?モバイルクライアントでログイン/ログアウトユーザーが必要な場合、トークンをどこかに格納する必要があります。JWTの場合、ログアウト時にトークンを無効にする必要があります。トークンを無効化するには、無効なトークンリスト(ブラックリスト)を作成する方法があります。うーん。テーブル/ファイルのサイズは、トークンがテーブルに保存されてユーザーに関連付けられ、ログアウト時に削除された場合よりもはるかに大きくなります。 それでは、JWTトークンの利点は何ですか? OAuthに関する2番目の質問は、サーバーと直接通信する場合に使用する必要がありますか?クライアントとサーバー間のもう1つのレイヤーの目的はトークンの発行のみですが、通信はoauthサーバーではなくメインサーバーと行われます。私が理解しているように、OAuthサーバーは、ユーザーの個人情報にアクセスするためのサードパーティアプリのアクセス許可(トークン)を付与する責任があります。しかし、私のモバイルクライアントアプリケーションはサードパーティではありません。
104 security  rest  api  oauth  https 

5
パブリックREST APIのOAuth2 ROPCと基本認証
ここで興味のある特定のユースケースは、公開されているサーバーエンドポイント(公開REST APIなど)に対してRESTクライアントを認証することです。 ここで最も簡単なソリューションは、基本認証です。しかし、ほとんどすべての状況において、OAuth2が優れた認証ソリューションとして宣伝されているとよく耳にします。 事は、あるのみ RESTサーバに対してRESTクライアント認証のために実現可能であるのOAuth2許可タイプがあるリソース所有者のパスワードの資格情報(ROPC)コード補助金と暗黙の補助金がため(認証サーバによってホストされている)UI / Webページを必要とするため、ログインしてクライアントアプリを手動で承認するユーザー。 ROPCが機能する方法は、リソース所有者のユーザー名/パスワードとクライアントIDをクエリ文字列パラメーターとして送信することです。これは、少なくともBase-64が資格情報をエンコードし、TLSで暗号化できるヘッダー内に送信するBasic Authよりも安全性が低い(IMHO)です! だから私は尋ねる:パブリックREST APIのコンテキストでは、OAuth2 ROPCは本当に基本認証よりも優れていますか?OAuth2 ROPCより安全なものは何ですか? 更新 AmazonのAWS向けの非OAuth2ベースのRESTセキュリティを説明するこの素晴らしい記事を読んだところです。これは基本的に、各RESTリクエストのハッシュが生成され、通常の(暗号化されていない)リクエストと一緒にサイドカーとして送信される秘密鍵ベースのソリューションです。クライアントとサーバーのみが秘密鍵を知っているため、サーバーがリクエストを受信すると(再び、通常のリクエスト+ハッシュされたリクエストを含む)、サーバーはクライアントの秘密キーを検索し、同じハッシュを通常のリクエストに適用し、次に、2つのハッシュを比較します。 これは、OAuth2のROPCよりもはるかに複雑で、複雑で、安全に聞こえます!ここで重要な何かを見逃していない限り、OAuth2 ROPCは単に送信client_idしてusernameおりpassword、クエリ文字列パラメーターとして...完全に完全に安全ではありません!このHMAC /ハッシュベースのソリューションは、はるかに印象的で安全なようです。 問題は、その記事の著者でさえ次のように述べていることです。 また、ある時点でOAuthを実装する必要があることをゆっくりと認識し、受け入れます。 バババウト?!?!OAuth2がこの賢いHMAC /ハッシュベースのソリューションよりも安全性が低い場合、この記事の著者はなぜOAuthをいつか受け入れる必要があると感じるのでしょうか。私は困惑している。
21 rest  oauth  https 

7
HTTPS経由の認証はアプリケーションを遅くしますか?
WebアプリケーションとRESTful Webサービスを構築しています。 Webサービスへのリクエストを認証する最良の方法に関するさまざまな記事を読んでいます。 私にとって最良のオプションは、HTTP基本認証を使用することです。私が読んだほとんどすべての記事は、認証はSSLまたは同等のもので暗号化されるべきだと言っています。 私はこれが何を含むのか完全にはわかりません。これは、Webサービス全体が安全なサーバー上にある必要があるということですか?これは遅くなりますか?

2
リプレイ攻撃を回避するにはHTTPSで十分ですか?
モバイルアプリ用のサーバーでいくつかのRESTメソッドを公開しています。 ユーザーが(モバイルアプリから)HTTPメソッドを構築する方法を傍受し、サーバーに再度送信することを避けたいと思います。例: モバイルアプリがリクエストを送信する ユーザーはプロキシを使用して、ネットワークで何が起こっているかを確認できます ユーザーは、モバイルが送信したリクエストを確認して保存します =>ユーザーがそのリクエストを手動で送信できないようにしたい HTTPS経由でサーバーを保護するのに十分ですか?
10 api  https 
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.