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

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
オープンソースのデスクトップTwitterクライアントのOAuth v1コンシューマキーとシークレットをユーザーに公開せずに保存するにはどうすればよいですか?
シッククライアント、デスクトップ、オープンソースのツイッタークライアントを作りたいです。言語として.NETを使用し、OAuth / TwitterラッパーとしてTwitterizerを使用しているため、アプリがオープンソースとしてリリースされる可能性があります。 OAuthトークンを取得するには、4つの情報が必要です。 アクセストークン(twitterユーザー名) アクセスシークレット(twitterパスワード) 消費者キー 消費者の秘密 PGP秘密鍵のように、2番目の2つの情報は共有されません。ただし、OAuth認証フローの設計方法により、これらはネイティブアプリ上に存在する必要があります。アプリケーションがオープンソースではなく、コンシューマキー/シークレットが暗号化されていたとしても、かなり熟練したユーザーはコンシューマキー/シークレットペアにアクセスできます。 だから私の質問は、この問題をどのように回避するのですか?デスクトップTwitterクライアントが消費者の鍵と秘密を保護するための適切な戦略は何ですか?

4
認証にサードパーティ(つまり、Google、Facebook、Twitter)を使用するRESTful Webサービスをどのように設計すればよいですか?
私の仕事のために、私たちが持っているいくつかのウェブサイトを動かすために使用する素敵なRESTfulウェブサービスがあります。基本的に、Webサービスを使用すると、サポートチケットを作成および操作でき、Webサイトがフロントエンドを担当します。Webサービスリクエストでは、認証ヘッダーを使用します。このヘッダーを使用して、呼び出しごとにユーザーとパスワードを検証します。 今年は、Webサイト上のユーザーがGoogle、Twitter、Facebook(おそらく他のユーザー)経由でログインできるように、ログインオプションを拡張することを検討しています。ただし、Webサービスがサードパーティの認証プロバイダーを使用して、ユーザーが本人であることを確認できるように、これをどのように設計するかについて多くの問題を抱えています。これを行うためのベストプラクティスはありますか? 現在、Webサイトでユーザー自身の認証を処理してから、現在のセッションをWebサービスバックエンドに登録する新しいsetSessionId呼び出しを使用することを考えています。Webサービスへの追加の各リクエストは、そのセッションIDを渡し、検証します。これらは大丈夫のように見えますが、私はこれを考えていないという私の頭の後ろの感覚を持っています、そして私のすべてのフォーラムの閲覧とoauthとopenidの仕様を読んでいるだけでもっと混乱させられます。これに取り組む方法のヒントはありますか?

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 
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.