OAuth2フロー-サーバーは認証サーバーで検証されますか?


10

私はOAuth2で頭を悩ませようと何度も読んでいましたが、それでも何か混乱しています。

クライアントがOAuthプロバイダー(Googleなど)を承認し、リソースサーバーがユーザーのプロファイルデータにアクセスできることを理解しています。その後、クライアントはアクセストークンをリソースサーバーに送信し、リソースを返すことができます。

しかし、どのドキュメントでもカバーされていないように見えるのは、クライアントアプリがリソースサーバーにリソースを要求し、それにアクセストークンを渡したときに何が起こるかです。これまでに読んだことはすべて、リソースサーバーが要求されたリソースで応答するだけであると述べています。

しかし、それは巨大な穴のようです。確かにリソースサーバーはアクセストークンを何らかの方法で検証する必要があります。そうしないと、古い要求を偽造して、古い、盗まれた、偽の、またはランダムに生成されたトークンを渡すだけで、それを受け入れるだけです。

これまでに読んだものは不完全だと感じるので、誰でも簡単にOAuth2の説明に従うことを私に向けることができますか?

回答:


8

それを見つけた。スペックに埋もれています。彼らは、リソースサーバーは認証サーバーでアクセストークンを検証する必要がありますが、それはドキュメントの範囲外であると言います。残念ですが、トークンの検証は重要な部分だと思いました。


1
重要な部分については、OAuth2の優先順位の背景について、このブログ投稿を読む価値があるかもしれません。
Lars Viklund、2012

1
それをありがとう、興味深い読み物。iOSアプリがgoogle、twitter、facebookなどで認証できるようにし、サーバーに何らかの承認を渡し、サーバーで検証してリソースへのアクセスを有効にしたいという点で、私の要件はかなり単純です。これがどのように機能し、どこで何をしなければならないかを理解するのが複雑なため、問題は予想よりも複雑であることがわかりました。
drekka 2012

より正確には、付録A:「リクエストの署名を検証するために、保護されたリソースは、トークン識別子を承認サーバーのイントロスペクションエンドポイントに送信して、そのトークンに必要な必要なキー情報を取得できます。この使用法の詳細は外部にありますこの仕様の範囲であり、拡張機能[...]で定義されます。
JulienD 2017年

2

トークンの検証は通常、2つの方法のいずれかで処理されます。

1)トークンは事前共有キーを使用して暗号で署名されています。これには、分散して増殖するシステムで使用するための明らかな短所があります。

2)Authorization Server(AS)は、トークン検証またはイントロスペクションのためのエンドポイントを提供します。この方法は、2015年10月にIETF RFC 7662で標準化されました。https://tools.ietf.org/html/rfc7662を参照してください。

このスタックオーバーフローの質問と回答には、GoogleとGithubの例が含まれています。


0

トークンを検証する方法の仕様を読みます。

https://tools.ietf.org/html/rfc7662

これが役立つことを願っています-クエリ/問題に答えた場合、plsは答えにマークを付けます


4
ソフトウェアエンジニアリングへようこそ。現在の形式では、この回答はGoogle の品質に関するガイドラインを満たしいません。回答はそれ自体で成立する必要があります。読者は外部リンクをたどって、理解を深めるか、出典を確認し、関連するコンテンツをここに引用する必要があります。
Thomas Owens
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.