Q&A
特に、アクセストークンはブラウザ外に打ち込む形での利用も可能ですが、それが10分ごとに発生しては、実用性をほぼ失います。
OAuth2を勉強している者です。
「認可コードグラント」のアクセストークンを取得するまでの部分がどうしても分かりません。
的外れな質問してたらすみません。
下の図で言うと、１～１１に当たります。
###分からない点
クライアントの認可リクエストに対して、直接アクセストークンを渡さずに認可コードを返し、クライアントは認可コードと一緒にアクセストークンをリクエストします。
なぜこのような二度手間の仕組みになっているのでしょうか？
アクセストークンを守るためでしょうか？
でも待って下さい。
認可コードは盗まれても、有効期限が標準10分程度に設定されているため安全とのことです。
それなら最初からアクセストークンを10分にすれば良いのではないでしょうか？
それじゃダメな理由が分かりません・・・。
分かる方どうか教えて下さい。
宜しくお願い致します。
回答2件
0
ベストアンサー
簡単に言えば、認可コードは漏洩のリスクがあるからです。
認可コードは、認可サーバーからのリレダイレクト時にURLにクエリ文字列として埋め込まれます。しかし、一般的に、URLに機密情報を埋め込むことは好ましくありません。これはウェブセキュリティのイロハでして、私の本（下記）でも説明しています。
このため、認可コードは「漏れるかもしれない」という前提で設計されています。
認可コードが漏れたらアクセストークンが得られるじゃないかという疑問が生じると思いますが、認可コードは10分間という時間制限に加えて、1回のみ利用可能（ワンタイム性）ですし、アクセストークンを得るには、クライアントIDとクライアントシークレットが必要であり、これらはリソースサーバー上に保存されているので、リソースオーナーを含む第三者には知り得ない値です。このため、認可コードそのものを認可トークンとして使用するのに比べて、はるかに安全になります。
認可コード漏洩の具体的な手口や、それらへの対策については下記の本に詳しく書いてあります。また、ネット上にも優れた記事が多数あるので、そちらも参考になります。
投稿2022/01/03 10:20
総合スコア11705
0
それなら最初からアクセストークンを10分にすれば良いのではないでしょうか？
10分ごとに再ネゴシエーションするのも手間ではありませんか？
投稿2022/01/03 07:43
総合スコア146018
回答有難う御座います。
要領を得ず申し訳ございません。いまだ理解できずにいます。
いただいた回答から考えてみました。
解釈は合っていますでしょうか？
間違いあればご指摘いただけると幸いです。
>10分ごとに再ネゴシエーションするのも手間ではありませんか？
「ネゴシエーション」でググると「通信条件や通信手順を事前に決定するもの」とありました。
つまり今回のフローで言うと、「ユーザ認証し許可範囲を決める認可を定める」部分の事かと思いました。
※画像でいうと１～７
その上で回答は、以下のように解釈しました。
認可サーバへの認証と認可（ネゴシエーション）の結果を認可コードとして取得して、アクセストークンと分ける事で次回以降のリソースへのアクセスは、アクセストークンを使えば良い。ネゴシエーションの部分は不要となる。
私が質問したように認可コードなしでアクセストークンだけにしてしまうと、10分おきに認可サーバへの認証と認可が必要になる。
>特に、アクセストークンはブラウザ外に打ち込む形での利用も可能ですが、
これはPOST送信のことでしょうか？
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2022/01/03 12:01