質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.37%
OAuth

OAuth(Open Authorization)は、APIを通して保護されたリソース(サードパーティのアプリケーション)へアクセスする為のオープンプロトコルです。

OAuth 2.0

OAuth 2.0(Open Authorization 2.0)は、APIを通して保護されたリソース(サードパーティのアプリケーション)へアクセスする為のオープンプロトコルです。

セキュリティー

このタグは、コンピューターシステムの安全性やデータの機密性に関連したトピックの為に使われます。

Q&A

解決済

2回答

6567閲覧

【OAuth2】認可コードグラントにおいて、直接アクセストークンを介さず最初に認可コードを介す理由が分かりません

pecchan

総合スコア591

OAuth

OAuth(Open Authorization)は、APIを通して保護されたリソース(サードパーティのアプリケーション)へアクセスする為のオープンプロトコルです。

OAuth 2.0

OAuth 2.0(Open Authorization 2.0)は、APIを通して保護されたリソース(サードパーティのアプリケーション)へアクセスする為のオープンプロトコルです。

セキュリティー

このタグは、コンピューターシステムの安全性やデータの機密性に関連したトピックの為に使われます。

0グッド

1クリップ

投稿2022/01/03 07:32

OAuth2を勉強している者です。
「認可コードグラント」のアクセストークンを取得するまでの部分がどうしても分かりません。
的外れな質問してたらすみません。

イメージ説明

下の図で言うと、1~11に当たります。

###分からない点
クライアントの認可リクエストに対して、直接アクセストークンを渡さずに認可コードを返し、クライアントは認可コードと一緒にアクセストークンをリクエストします。

なぜこのような二度手間の仕組みになっているのでしょうか?

アクセストークンを守るためでしょうか?
でも待って下さい。
認可コードは盗まれても、有効期限が標準10分程度に設定されているため安全とのことです。
それなら最初からアクセストークンを10分にすれば良いのではないでしょうか?
それじゃダメな理由が分かりません・・・。

分かる方どうか教えて下さい。
宜しくお願い致します。

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答2

0

ベストアンサー

簡単に言えば、認可コードは漏洩のリスクがあるからです。
認可コードは、認可サーバーからのリレダイレクト時にURLにクエリ文字列として埋め込まれます。しかし、一般的に、URLに機密情報を埋め込むことは好ましくありません。これはウェブセキュリティのイロハでして、私の本(下記)でも説明しています。

体系的に学ぶ 安全なWebアプリケーションの作り方 第2版

このため、認可コードは「漏れるかもしれない」という前提で設計されています。
認可コードが漏れたらアクセストークンが得られるじゃないかという疑問が生じると思いますが、認可コードは10分間という時間制限に加えて、1回のみ利用可能(ワンタイム性)ですし、アクセストークンを得るには、クライアントIDとクライアントシークレットが必要であり、これらはリソースサーバー上に保存されているので、リソースオーナーを含む第三者には知り得ない値です。このため、認可コードそのものを認可トークンとして使用するのに比べて、はるかに安全になります。

認可コード漏洩の具体的な手口や、それらへの対策については下記の本に詳しく書いてあります。また、ネット上にも優れた記事が多数あるので、そちらも参考になります。

OAuth徹底入門 セキュアな認可システムを適用するための原則と実践

投稿2022/01/03 10:20

ockeghem

総合スコア11705

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

pecchan

2022/01/03 12:01

回答いただき有難う御座います。 >認可コードが漏れたらアクセストークンが得られるじゃないかという疑問が生じると思いますが、 はい、そう思いました・・・。 >認可コードは10分間という時間制限に加えて、 これはよく見かけました。 >1回のみ利用可能(ワンタイム性)ですし、 これは知りませんでした!!! >アクセストークンを得るには、クライアントIDとクライアントシークレットが必要であり、これらはリソースサーバー上に保存されているので、リソースオーナーを含む第三者には知り得ない値です。 あ、なるほど!確かに最初にリソースサーバへまず登録しますね。 >認可コードそのものを認可トークンとして使用するのに比べて、はるかに安全になります。 認可コードが漏れたとしても ワンタイム性+リソースサーバー上の情報で大丈夫ということですね。 やっと理解できました(T_T) 有難う御座います!! >体系的に学ぶ 安全なWebアプリケーションの作り方 第2版 注文させていただきました。 やっとスッキリしました! 有難う御座います!
guest

0

それなら最初からアクセストークンを10分にすれば良いのではないでしょうか?

10分ごとに再ネゴシエーションするのも手間ではありませんか?

投稿2022/01/03 07:43

maisumakun

総合スコア145939

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

maisumakun

2022/01/03 07:46

特に、アクセストークンはブラウザ外に打ち込む形での利用も可能ですが、それが10分ごとに発生しては、実用性をほぼ失います。
pecchan

2022/01/03 09:18

回答有難う御座います。 要領を得ず申し訳ございません。いまだ理解できずにいます。 いただいた回答から考えてみました。 解釈は合っていますでしょうか? 間違いあればご指摘いただけると幸いです。 >10分ごとに再ネゴシエーションするのも手間ではありませんか? 「ネゴシエーション」でググると「通信条件や通信手順を事前に決定するもの」とありました。 つまり今回のフローで言うと、「ユーザ認証し許可範囲を決める認可を定める」部分の事かと思いました。 ※画像でいうと1~7 その上で回答は、以下のように解釈しました。 認可サーバへの認証と認可(ネゴシエーション)の結果を認可コードとして取得して、アクセストークンと分ける事で次回以降のリソースへのアクセスは、アクセストークンを使えば良い。ネゴシエーションの部分は不要となる。 私が質問したように認可コードなしでアクセストークンだけにしてしまうと、10分おきに認可サーバへの認証と認可が必要になる。 >特に、アクセストークンはブラウザ外に打ち込む形での利用も可能ですが、 これはPOST送信のことでしょうか?
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.37%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問