カミナシ エンジニアブログ

株式会社カミナシのエンジニアが色々書くブログです

トップ > 認証認可学習のすゝめ

認証認可学習のすゝめ

カミナシの認証認可ユニットでソフトウェアエンジニアをやっているトモ=ロウです。
先日、過去に弊社で行った共通ID基盤構築プロジェクトに関するブログ記事を公開したのですが、お読みいただけたでしょうか？まだ読んでいない方は是非ご一読ください！

スタートアップがゼロから作る共通ID基盤：立ち上げ〜ID統合まで道のり（前編） - カミナシ エンジニアブログ

スタートアップがゼロから作る共通ID基盤：ID統合のその先へ（後編） - カミナシ エンジニアブログ

さて、今回は前半に「認証認可完全初心者だった自分が如何にしてID基盤構築プロジェクト完遂に貢献するに至ったか」という視点で僕がどのように認証認可の学習をしてきたかについてお話しします。そして後半は「今から学習し直すならどうするか」というテーマで現時点で僕の考える最速の「知の高速道路」を紹介してみようと思います。
前回の記事が少し硬めの感じになってしまったので、今回は片手間で読める記事に仕上げたつもりです。
認証認可の世界に少しでも興味がある方には是非読んでいただきたいです！

※「認証認可学習のすゝめ」と大きく謳っていますが、本記事はOAuth2.0, OpenID Connectにフォーカスした内容になっています

私が通った道

1. とりあえず OpenID Connect を調べる

カミナシの認証認可ユニットには、もちろん私のようなカミナシに来てはじめて認証認可を学んだメンバーだけではなく、認証認可に精通したメンバー(@manaty0226)が在籍しています。
ID基盤を作り始めた当時、彼はこう言いました。「よし、 OIDC でいこう」。当時の僕は OIDC というワードを何となく聞いたことがあるぐらいで、その中身は何も知りませんでしたが、とりあえず「なるほど、 OIDC ですね？」みたいな反応をした気がします。
「一応知ってます」みたいな反応をしてしまったため、急いで OIDC のことを調べないといけなくなりました。

何を言ってるか分からない、 OpenID Connect Core 1.0

このままではまずいと考えた僕はまず OpenID Connect Core 1.0 を読みました。するといきなりこんなことが書いてあります。

OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 [RFC6749] protocol.

嫌な予感がしました。「あーこれは OAuth2.0 のことを知らないと読めないやつかな？」。この予感はすぐに確信に変わります。

3.1 Authentication using the Authorization Code Flow

「Authorization Code Flow」って何やねん。 どうやら RFC6749 を先に読まないといけないみたいです。しかし、僕には早急に「一応知ってます」な状態にならないといけないプレッシャーがかかっていました。
そこで僕がとった選択は、「日本語で書かれたブログ記事などで OAuth の知識を補完しつつ、 OIDC の仕様を理解する」という方法でした。

なんとなく分かるけど、なんとなく分からない

様々なブログを参照して OAuth の各フローを理解しました。以前知らなかった「Authorization Code Flow」のシーケンス図は完全に頭に入っています。では、改めて OpenID Connect Core 1.0 と対峙しましょう。
「うーんなんとなく分かるけど、なんとなく分からないな（？）」。
OAuth のことを調べたと言っても、ただシーケンスを丸暗記しただけで、「nonce って何？」「PKCE？」「なんでインプリシットフローはダメなの？」みたいな疑問が常に溢れていました。詰まるところ、なぜ OAuth がこのようなシーケンスになったのか、という本質部分への理解が欠いている状態です。
認証基盤のとある機能に関して「画期的な仕組みを思いついた！」と思ったらアンチパターンだった、みたいなことがよくありました。

取りこぼした知識を集める日々

限界を感じた僕は、ここでやっと「ちゃんと体系的に学習しよう」という気になりました。
OAuthやOpenID Connectについて初学者でもわかりやすい技術同人誌を多数出版されているAuth屋さん(@authyasan)

を読み、その後

等々を読んで、少しずつ知識を蓄えてきました（もちろん今もその途中です）。
そうしてある程度知識がついてくると、「これは早めに読んでおくべきだな」とか、「これは必要になれば読めばいいやつだな」とかっていうのが何となく見えてきます。次章ではその辺りの勘所を読者の皆さんに伝えたいと思っています。

初心者の僕へ

さて、やっと本題です。忙しい方はここだけ読んでもらえれば大丈夫です。

まずはブログなどで OAuth を概観すべし

いきなり仕様を読むのは普通は厳しいと思うので、まずはブログ等で概要を知ると良いと思います。人によってはいきなり書籍に入る方がやりやすい人もいるかもしれませんが、基本的に最新の仕様等はインターネット上で議論されるため、インターネットで情報収集するコツを掴んでおくと役に立つかもしれません。
ちなみにネットの情報はたまに少し真偽の怪しい内容のものがあったりするので、そこは注意が必要です。
ブログに関してはたくさんの記事を読みましたが、特に以下の方々の記事をよく拝見していました（いつもお世話になっております）。

  • ヘッドレスな OAuth/OIDC エンジンを提供するサービスを運営されている Authlete さんの記事（CEO 川崎さんの個人記事を含む）
  • OpenID Foundation Japan でも活躍されている ritou さんの記事
  • OpenID Foundation の理事長を務められている Nat Sakimura さんの記事

OAuth に関する書籍を読むべし

ブログ記事だけでは理解しきれない知識が必ずあるはずなので、書籍を使って補完しましょう（前述の通り、好みによってはいきなり書籍でも良いと思います）僕の個人的なお勧めは「Auth屋」さんの「雰囲気OAuth本」です。
書籍を読むことで OAuth の全体像がかなりクリアに見えてくると思います。個人的には RFC6749 や、その他の OAuth 関連仕様を直接参照するのはこの後がいいと考えています。もちろんいきなり仕様を読んで理解できる人もいるとは思いますが、「技術的に理解できること」と「なぜこの仕様があるのかという本質部分を理解すること」の間に大きな隔たりがあり、僕は仕様を順番に読むだけでは「なぜこの仕様があるのかという本質部分を理解する」ことはかなり難しいと考えています。

満を持して仕様を読むべし

ここまでくると OAuth の成り立ちや仕組みがかなりの解像度で理解できていると思います。ついに仕様の海に飛び込む時が来ました。
まずは https://oauth.net/2/ を見てみましょう。 OAuth 2.0 の周りにはたくさんの仕様があります。もちろん上から順番に全部読んでもいいですが、さすがに大変なので（僕はまだ半分も目を通せていないです）個人的にはまずは Proof Key for Code Exchange by OAuth Public Clients を読むことをおすすめします。 Proof Key for Code Exchange (PKCE) という仕組みは、

  • HTTP というステートレスなプロトコルの上でどのように「認可リクエストを送った人」と「トークンリクエストを送った人」が同一であることを担保するか

という、 OAuth が長きに渡って戦ってきた問題への根本的なアプローチとして存在すると考えています。堅牢なフローを構築するためには必要不可欠な要素なので、一読する価値はあるはずです。きっと具体的な手法や実装方法以上に得られるものがあるでしょう。

また、以下のあたりを読んでみるのも面白いかもしれません。

これらは本質的には

  • どのように「トークンを受け取った人」と「トークンを使った人」が同一であることを担保するか

という問題にアプローチしたものだと考えています。
このように OAuth に関する基礎的な理解がある状態で仕様を読むことで、「それらの仕様が解決しようとしている本質的な課題」が自然と理解できるようになってきますし、そうなると仕様を読むのが楽しくなってきます。
また、一度 OAuth に対してしっかり向き合ったことで、もし読んだ仕様がよく分からない場合でも次に何をすれば良いか、が自然と見えてきます（分からなかった文献が分かるようになった経験って自信になりますよね）。この状態までこられればもう後はどうにでもなりますし、ある意味ここが一つのゴールだと考えています。
何にでも言えることかもしれませんが、認証認可を学習するときにあらゆる仕様を全て把握している必要はないと思っています。必要なのは仕様を読むコツと自信で、具体的な仕様の多くは必要なときに都度参照すれば十分事足りるというのが持論です。ちなみにここまでずっと OAuth の話をしてきましたが、この時点で OpenID Connect Core 1.0 もすんなり読めるようになっていると思いますし、 OIDC に限らず OAuth がベースになっている仕様は概ね読めるようになっているはずです。

晴れて OIDC を「一応知ってます」な人になることができました。もうどんな仕様でもかかってこいという気持ちになってきましたか？そうです。仕様の海の航海術を手にした我々に死角はありません。このまま OAuth を深掘っても良いですし、最近話題のパスキーやMCPの認可に関して調べてみても面白そうです。興味関心の赴くままに好きな仕様を学習していきましょう。

最後に

一通り書いた後に読み返してみたところ、想定してたより当たり前のことを書いてるなと思ってしまいました。当たり前のことを当たり前にやるって難しいですよね（？）。
ところでこんなブログを書いてますが、実際のところ「私が通った道」で紹介したやり方がそれほど悪かったとは思っていません。ただ、人間って二周目は上手くやりたいってどうしても思ってしまいますよね。本当は一周目に経験した回り道の中に大事な何かがあったかもしれませんが、それは僕にはもう分かりません。
僕がこの記事で本当に伝えたかったことは、「言っちゃったから何とかしないと…」みたいな邪な理由でスタートしても、最後には何とかなるってことです。 OAuth/OIDC って内容を理解するだけならぶっちゃけそんなに難しくないので、やる気があればどうにでもなると思います。もしやる気がある人がいたら、この記事をちょっとだけ参考にしてみてもらえると嬉しいです。そしていつか無駄に二周目に思いを馳せたりしてみましょう。

この記事を書いていてふと「最近あまり仕様を読んでないなー」と思いました。もっとたくさんの仕様が読めるよう、より一層精進する気持ちで溢れています。そんな僕と一緒に精進してくれる仲間をカミナシの認証認可ユニットでは募集しています！

herp.careers

herp.careers

最後までお読みいただきありがとうございました！