SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

Developers Summit 2023 KANSAI セッションレポート(AD)

これからのOAuth/OIDCで知っておきたいこと。最新の拡張仕様やAuthleteを活用した実装方法

【Session8】認証・認可技術の最新動向:Authleteが考える「これからのOAuth/OIDC」と基盤構築のアプローチ

  • X ポスト
  • このエントリーをはてなブックマークに追加

 API認可にOAuth 2.0(以下、OAuth)、ID連携にOpenID Connect(以下、OIDC)を使うことは、いまでは当たり前の選択になっており、OAuth/OIDC基盤を構築した経験のある開発者も増えている。その一方で、OAuth/OIDCの最新動向をきちんと掴んでいる人はそれほど多いわけではない。そこでOAuth認可サーバーやOpenID Connectアイデンティティプロバイダをセキュアかつシンプルに実装するためのAPIサービスを提供するAuthleteのソリューション戦略担当VPの工藤達雄氏とソリューションコンサルタントの森川将聖氏の2人が登壇、2023年に今知っておくべきOAuth/OIDC拡張仕様のポイント、およびAuthleteを活用した実装アプローチについて解説した。

  • X ポスト
  • このエントリーをはてなブックマークに追加

OAuth/OIDCのセキュリティ改善に役立つ「PAR」「mTLS」「DPoP」

 OAuth/OIDC拡張仕様のポイントを解説すべく、最初に登壇したのは工藤氏。Authleteは2015年に設立された、OAuth/OIDCソリューション「Authlete」を展開する日本のAPIセキュリティスタートアップ。OAuth/OIDC分野に特化して事業を展開する同社は、Web記事をはじめ、自社公式のYouTubeチャンネル書籍などで、OAuth/OIDCに関する情報を広く提供している。

 OAuthはアクセストークンを用いたAPI認可フレームワークである。フローは図の通り。認可サーバーはエンドユーザーの認証などを行い、同意確認をする。その後、APIを呼び出す側(クライアント)にアクセストークンが渡り、それを使ってAPIが呼び出されたときに、APIサーバー(リソースサーバー)は、アクセスを許可するか判断する。一方のOIDCはIDトークンを用いたID連携プロトコル。フローはOAuthをベースとし、IDトークンを、アイデンティティプロバイダからRP(Relying Party)に渡し、エンドユーザーのRPへのアクセスを認可する仕組みである。

OAuth/OIDCの処理フロー
OAuth/OIDCの処理フロー

 OAuthもOIDCも、昨今登場した技術ではない。「OAuthの基本的なところは2012年にProposed Standard RFC(Request for Comments)になっている。またOIDCも2014年に仕様が確定。いずれも10年前後使われ続けている技術」と工藤氏は説明する。とはいえ、当時のまま使われてきたわけではない。「拡張仕様が登場したり、当初は問題なかったが、今では使うべきではないパターンになってしまったりと、使い方もいろいろ変わってきている。そこで、これからに向けて覚えておくべき2つのポイントを紹介したい」(工藤氏)

工藤氏
株式会社Authlete ソリューション戦略担当VP 工藤 達雄氏

 まずはセキュリティの改善。OAuthでは認可リクエストにまつわるさまざまな課題があった。OAuthのフローの中では、クライアントが認可サーバーに対して、「こういうアクセストークンが欲しい」という認可リクエストを行う。この認可リクエストはWebブラウザを介するリダイレクトという形で、ユーザーを巻き込んでユーザー認証を行い、アクセス承認を戻すというフローになる。このリダイレクトの存在によって、いろいろな不都合が発生していた。中でも最も大きな不都合が、「認可サーバーは直接クライアントと通信していないので、クライアントを認証できないこと」と工藤氏。クライアントから認可サーバーへの認可リクエストの送受信は、Webブラウザを介する間接通信となるため、認可サーバーはクライアントの真正性を確認できないのだ。また認可リクエストの内容をWebブラウザから秘匿できないこと、大きなサイズの認可リクエストを送信できないという課題もあった。

 そこで新たな仕様として策定されたのが、RFC 9126「PAR(Pushed Authorization Requests)」である。まずクライアントは認可サーバーのPARエンドポイントに、response_typeなどのパラメータを含む「認可リクエストの内容」を登録する。PARエンドポイントはそのレスポンスとして、クライアントにrequest_uriを返却する。このrequest_uriは、その後クライアントが送信する認可リクエストに含められる。PARはこのように、クライアントが認可サーバーに、認可リクエストの内容を直接通信によって登録する仕組みである。これにより、認可サーバーがクライアントを認証できるようになるだけではない。「リクエストの内容をWebブラウザから秘匿可能になる。またWebブラウザを介さないので、大きなサイズのリクエストも送信できるようになります」(工藤氏)

認可リクエスト内容を直接通信にて登録する仕様「PAR」
認可リクエストの内容を直接通信で登録する仕様「PAR」

 またOAuthではアクセストークンの扱い方にも課題があった。広く用いられているアクセストークンは持参人(Bearer)型であり、そのアクセストークンを誰が使うかは限定できない。「そのため、アクセストークンの不正利用を防ぐ術がなかった」(工藤氏)という。

 この課題を解決するには、認可サーバーがアクセストークンを発行する際、そのトークンにクライアント情報を紐付け、リソースサーバーがAPIリクエストの受付時にその紐付けを検証して、送信者の正当性を確認することが有効である。その実現方法として、工藤氏が挙げたのはTLSクライアント証明書を使う方法(RFC 8705で定義。通称mTLS)と、クライアントが動的に生成した公開鍵を使う方法(同RFC 9449。通称DPoP)の2つ。DPoPは、シングルページアプリケーション(SPA)など、mTLSの適用が難しい分野をカバーできる技術である。

OAuth/OIDCの適用シーンを広げる「RAR」「CIBA」

 もう一つのポイントは、さまざまなユースケースへの対応力の強化。OAuthにおけるスコープとは、「APIの認可リクエストやトークンリクエストをする際に、こういう権限のアクセストークンをください、ということを示す値のこと」と工藤氏は説明する。対象リソースの範囲や種類、リソースの参照/更新の区別、特定/期間限定の取引などが該当する。仕様上、スコープはたんなる文字列であり、構造化やパラメータ化は可能だが、表現力に限界があった。そこでRAR(RFC 9396)では「認可詳細」を定義できるようし、表現力の向上を図っている。

PARで認可詳細によるスコープの表現力が向上
RARの認可詳細によってスコープの表現力が向上

 また対応力の強化では、最近登場した新しい仕様というわけではないが「CIBA」も見逃せないという。CIBAはユーザー認証・同意確認に、典型的にはAPI・ID情報提供側の「公式モバイルアプリ」を用いるための仕組み。一般的なOAuth/OIDCのフローでは、Webブラウザのリダイレクトを通じて認可リクエスト・レスポンスをやり取りし、ユーザー認証・同意確認を行う。CIBAを用いると、このリダイレクトがなくなり、ユーザー認証・同意確認は公式モバイルアプリが実施することになる。これにより、ショッピングセンターのPOS端末に会員証をかざすと、ユーザーの手元の銀行アプリが取引承認を求めたり、コールセンターのオペレータに購入を伝えると、ユーザーの手元の決済アプリが購入確定を求めたり、というフローが可能になる。つまりCIBAは、セキュリティを担保しつつ、適用分野を拡大できる技術なのである。

次のページ
Authleteを活用したOAuth/OIDC実装パターン

関連リンク

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
Developers Summit 2023 KANSAI セッションレポート連載記事一覧

もっと読む

この記事の著者

丸毛 透(マルモ トオル)

インタビュー(人物)、ポートレート、商品撮影、料理写真をWeb雑誌中心に活動。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

CodeZine編集部(コードジンヘンシュウブ)

CodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

中村 仁美(ナカムラ ヒトミ)

 大阪府出身。教育大学卒。大学時代は臨床心理学を専攻。大手化学メーカー、日経BP社、ITに特化したコンテンツサービス&プロモーション会社を経て、2002年、フリーランス編集&ライターとして独立。現在はIT、キャリアというテーマを中心に活動中。IT記者会所属。趣味は読書、ドライブ、城探訪(日本の城)。...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

提供:株式会社Authlete

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/18411 2023/10/24 15:04

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング