(OIDC)がどういうものか、どう使うのかについて知るために読んだものについてまとめておく。2を利用したアプリケーションの開発経験はあるとします。2を拡張した認証プロトコルとなっている。2を使ったアプリケーション(認可サーバ、クライアント両方)の開発に携わった経験はなんどかあったものの、念のため復習した。Action"を読んだ。セキュアな認可システムを適用するための原則と実践』。2の各グラントタイプを、認可サーバ、クライアント、リソースサーバーそれぞれの役割と認可のフロー、それらを実現するコードで説明している。コードは基本的にJavaScriptで書かれていて、GitHubにもリポジトリ(oauthinaction/oauth-in-action-code)がある。認可サーバ、クライアント、リソースサーバそれぞれについて、よくある脆弱性とその対策を説明している。記述がよくも悪くも冗長なので、コードやシーケンス図を読んで、わからないところがあれば本文で補完していくような読みかたがいいかもしれない。Action"の後半で、OIDCについて1章割いて説明している*1。OAuthでは誰が認可したのかはクライアントからわかりえないので認証ではない、という話に始まり、他の章と同様に実装を交えてOIDCを説明している。Connectの違いを整理して理解できる本もう少し理解を整理するためにAuth屋さんが頒布している次の本も読んだ。authya.booth.pmこの本のいいところは、いわゆる「OAuth認証」から始めて、OIDCがなぜ出てくるかまで次のような流れで説明しているところだと思う。Connectの違いを〜』にも書いてあるが、OIDCのRFCで説明しているのでそちらも確認した。2/OIDCの周辺技術に関して、いくつか文書を読んだ。providerからIDトークンとして取得するので、それぞれ注意点やベストプラクティスをあらためて把握するためにRFCを読んだ。Action"の脆弱性に関する部分と少し被るが、こちらも生まれうる脆弱性とその対策について広く説明している。2/OIDCのRFCは長大なので、ひとまずライブラリの実装と標準の仕様を比較するときなどに読む方針にしている。Connectを実装したライブラリコードを読むと理解が深まりやすいので、なにか現実のライブラリを読むのはいいことだと思う。注意点は、あくまでもRFCなどが説明する仕様が正であって、実装はなんらかの差異や不足があると認識しておいたほうがよいこと。それも考慮してコードを読むとコントリビューションチャンスも生まれそう。partyとして認証サーバを叩いたりコードを読んで理解を深めた。APIと署名付きのIDトークンでやっていると考えると腑に落ちた。Connectの違いを〜』はそのあたりの観点を提供してくれたので大変助かった。いえ、それなりにいろいろ読んだものの、細かいパラメータや様々な拡張仕様など、わからないことはまだまだあるので、必要に応じて身につけていきたい。2017の23日目の記事です。引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。