挫折した人向けにふんわりと認可コードとインプリシットの違いについて解説

挫折した人に向けてふんわり認可コードとインプリシットグラントの違いについて解説する

◆ Live配信スケジュール ◆
サイオステクノロジーでは、Microsoft MVPの武井による「わかりみの深いシリーズ」など、定期的なLive配信を行っています。
⇒ 詳細スケジュールはこちらから
⇒ 見逃してしまった方はYoutubeチャンネルをご覧ください

【5/21開催】Azure OpenAI ServiceによるRAG実装ガイドを公開しました
生成AIを活用したユースケースで最も一番熱いと言われているRAGの実装ガイドを公開しました。そのガイドの紹介をおこなうイベントです!!
https://tech-lab.connpass.com/event/315703/

今回は、インプリシットグラントと認可コードグラントの違いに注目してまとめてみました。初見で出会ったときはほぼ一緒やないか！と突っ込んでしまったのですが、途中一緒で終盤になると別れる二人を認識することができて、やっと違いが認識できるようになりました。挫折した人に向けてふんわり解説する輪読会シリーズ

1 ご挨拶
2 OAuth認証の登場人物
3 「認可コード」と「インプリシット」は何が違うの？
4 まとめ

ご挨拶

どもども！泣きながらOAuth認証に入門するシリーズをしれっと始めてしまった龍ちゃんです。輪読会の課題図書がOAuth認証を学ぶ書籍だったので、泣きながら入門をして大号泣しながらまとめています。

今回はグラントタイプの中で「認可コードグラント」と「インプリシットグラント」の違いについて紹介していきます。この二つのグラントタイプは似ていたので、理解するのに苦労しました。このブログで理解することができることは以下になります。

クライアントタイプ
認可コードグラントとインプリシットグラントの違い

グラントタイプは4つあるのですが、フロントエンドエンジニアとして特に使用する可能性があるのが、「認可コード」になります。それでは本題のほうに入っていきたいと思います。

今回のブログは、前回記事「何も知らない人向けにふんわりOAuth認証について解説する：超初心者向け」のシリーズという形で進んでいきます。もし、超初心者の方がいればそちらを読んで、助走をつけてきてください。僕が今回勉強するにあたって使用した書籍は以下になります。

後はネットの記事をいろいろ読んでみました。

そして、一度「認可コード」・「インプリシット」について学習して挫折した人向けの記事となっています。間違いがあった場合は、ご連絡ください。

OAuth認証の登場人物

まずは、登場人物を押さえておきましょう。主に4人の登場人物が登場します。

「リソースオーナー」と書いていますが、操作するあなた（ユーザー）として理解するとよいと思います。各登場人物が通信やアクションを通して認証・認可が実行されます。処理の流れとしては、以下のイメージを持っておけば、ひとまずはOKです。

処理の流れとしては、以下になります。

ユーザーがクライアントにアクセスする（アプリケーションにアクセス）
クライアントから認可サーバーにリクエストを送信する
認可サーバーからユーザーに確認画面を提示する
ユーザーが承認をする（クライアントからのアクセスを承認する）
認可サーバーからクライアントにアクセスするためのカギを渡す
クライアントがリソースサーバーにカギを使ってアクセスする

多少はややこしいかと思いますが、「ユーザーがクライアントを介して外部のサービスと通信するときに、ユーザーであることを確認して通信を行うためのカギを発行する仕組み」という言葉で書き直すことができます。

さて、それではグラントタイプの比較に入っていこうと思います。

「認可コード」と「インプリシット」は何が違うの？

グラントタイプは、4つの種類があります。

OAuth認証の登場人物と内部の流れが異なるものです。ユーザーが登場しないパターン（クライアントクレデンシャル）やパスワードとIDを直に送信するというパターン（リソースオーナーパスワードクレデンシャル）も存在しています。今回はこの2つのグラントタイプについてはすっ飛ばします。

「認可コード」と「インプリシット」のシーケンス図を見比べるとよく似ています。具体的な処理の部分まで確認すると、権限の委譲までは同じシーケンスとなっています。異なる部分としては、クライアントと認可サーバーのやり取り部分になります。

異なる点として、推奨される「クライアントタイプ」が異なります。いきなり新しい言葉が出てきましたが、「クライアントタイプ」は2種類あり定義としては以下になります。

「クライアントタイプ」の見分けとしては、OAuth認証を使用するためのパラメータが覗けるかどうかという点です。モバイルアプリやJavaScriptを通して認証をする場合は、通信にパラメータを載せてやり取りを行うため情報を覗くことができます。一方でサーバーサイドアプリケーションの場合は、サーバー側でやり取りが行われるため、情報を覗くことはできません。そういったイメージを持つと「クライアントタイプ」の理解がやりやすいです。

パブリック：インプリシットグラント（非推奨） or 認可コードグラント＋PKCE
コンフィデンシャル：認可コードグラント推奨

振り分けとしては上記になります。2023年ではインプリシットグラントは非推奨となっています。代わりに認可コードグラント＋PKCEを採用するように促されています。

中身の処理で異なる点としては、「アクセストークンを取得するタイミングと手法」です。「アクセストークン」とは、APIとの通信で権限が許可されているかの情報が詰まった鍵をイメージしてもらえればオッケーです。

「インプリシット」が一番簡単にアクセストークンが取得でき、「認可コード」・「認可コード＋PKCE」の順序で手順が複雑になっていきます。このアクセストークンを取得するまでの「複雑さ」は、セキュリティの「強固さ」に直結していきます。

「インプリシット」の場合は、1度目のレスポンスでアクセストークンを取得することができます。「認可コード」の場合では、1度目のレスポンスで「認可コード」を取得して、2度目のレスポンスでアクセストークンを取得します。最後に「認可コード＋PKCE」の場合では、1度目のリクエスト時に鍵穴を登録して、レスポンスとして「認可コード」を受け取ります。2度目のリクエスト時に「認可コード」と「鍵」を送付して、アクセストークンを受け取ります。

しれっと「認可コード＋PKCE」が出てきましたが、こちらで解説しているので読んでみてください。