2017-03-21 9 views
0

OAuth2を使用して承認するWebサービスを作成しています。私はC#とWCFを使用していますが、これは本当に私の質問には関係ありません。前にOAuthを使ったことはありませんでしたが、私は研究を続けてきました。私は "彼らは実際にこのサービスを使用する権限を持っていることを確認する"上に物事の終わりです。私はOAuth2が今どのように機能しているかについてかなり良い考えがあると思いますが、その1つの側面はまだ私を混乱させます。OAuthの秘密についてはどういう秘密がありますか?

OAuth2はトークンベースです。トークンは単なるテキストであり、アプリケーション(私の場合はWebサービス)と認可サーバーが知っている "秘密"を含むいくつかの情報が含まれています。秘密は単なるテキストフレーズでも、セミランダムな文字列(GUIDのようなもの)でもかまいません。これは、ユーザーが認可サーバーに連絡し、その秘密を入手したことを「証明」します。私が混乱しているのは、ユーザーが過去に承認サーバーに連絡したことが証明されたように見えるだけです。実際、それはそれを証明するものでもありません。ユーザーが秘密を知っていることを証明するだけです。残りのトークン(役割、期間、その他のものなど)はすべて偽造することができます。ユーザーがアクセスしたいサービスに対して1つのトークンを取得すると、好きなだけ情報を改ざんした新しいトークンを作成することができます。実際に、悪意のある個人が自由に使用できるように、何千もの「秘密」が設定された多数のサーバーが存在する可能性があります。もちろん、これは頻繁に起こることはありませんが、非常に可能です。

私は正しいですか、または何かが欠落していますか?これはOAuth2の弱点ですか?

答えて

1

リソースサーバー(または「サービス」)がトークンを受け取るたびに、それを検証する必要があります。トークン・タイプに応じて、認可サーバーにある秘密鍵で作成された署名を検査することも、認可サーバーに呼び出してトークンを検証することもできます。この方法では、ユーザーはトークンを偽造することはできません。署名を偽造したり、認証サーバーが発行しなかったトークンを検証することは不可能です。

FWIW:「トークン」と「クライアントの秘密」と、おそらく認可サーバーの秘密キーが混在しているようです。彼らはすべて異なった概念です。

+0

ありがとうございました!私が読んだリソースの中には、秘密鍵で作成された署名や、検証のためにASに連絡することについて話したものはありません。私が見た限り、トークンには秘密情報やその他の情報が含まれていました。 AS自体に連絡するか署名を確認することはトンを意味し、私はそれを前に見つけていないのが不思議です。私はより良い情報源を見つけなければならないと思う。再度、感謝します! – Frecklefoot

関連する問題