以前、「OAuth2 / OpenID Connectによる課題解決」と言うタイトルで投稿を行いましたが、今回は、タイトルを「OAuth2 / OpenID Connect課題解決 備忘録」に変更しての連載 第1回目の投稿になります。今回は、独自認証方式を変えて、OAuth2.0 / OIDCを導入すべきかどうか？という相談です。

＜質問＞

　当初は（以前、初めてOAuth2認証を導入した際の経験から）OAuth2認証は難しいので、URLを貼り付けるダケの連携にする予定でした。

　しかし、私の知らないトコロで、もっと密に連携したいという意見が出て、やっぱりSSOしようということになっていたそうです。その方式案が先日出てきたのですが、ザックリ言うと「アプリA」起動時に「アプリB」からアカウント情報（パスワード含む）をPOSTし、「アプリA」のアカウント情報を上書きするというモノでした。

　昔のSSOってこんな感じだったと思うのですが、それだったら素直にOAuth2連携してもあまり工数的には変わりが無いのかな？とも思っておりますが、ご意見を頂けますと助かります。

＜回答＞

　OAuth2.0 / OIDCなど、オープンスタンダードのプロトコルに比べ、独自実装は、作り手が完全に理解しているから使い易いのかもしれませんが、オープンスタンダードのプロトコルであっても、一度、理解してしまえば、実装に掛かる工数は変わらないと思いますし、以降、色々な案件でその知識を利用することができます。

　また、最も重要なのは、オープンスタンダードのプロトコルは、考慮漏れに対するチェックが十分に行われているところでしょうか（例えば、上記の方式は大切なクレデンシャル情報をPOSTしてしまっていますので、このまま進めてしまうと、後々、一時トークン化して裏でDB共有させて...みたいな再検討が発生したりします）。

例えば、

＜参考 1 ＞

• マイクロソフト系技術情報 Wiki
  > UserAgentでOAuth2のTokenを取得するベスト・プラクティス
• スマホ向けベストプラクティス (RFC 8252 ... OAuth 2.0 for Native Apps)
• 認可コード横取り攻撃への対抗策 (RFC 7636 ... OAuth PKCE)

　などを参照すれば明らかですが、

　オープンスタンダードのプロトコルは、草案から勧告まで多数の有識者により多数のレビューが重ねてられており、また、オープンな開発言語 / ツールを使用して、ライブラリに依存せずセキュアに実装することが出来ます。

　また、以下に纏めたように、

＜参考 2 ＞

• OpenID / OAuth / OpenID Connect - マイクロソフト系技術情報 Wiki

　特に、OAuth2.0の派生のプロトコル群は、「OAuth2 -> OAuth2.0拡張 -> OpenID Connect -> Financial API (FAPI)」と、継続的に拡張を続けており、スマホなどを含めた Publicクライアント + WebAPI の認証で、ほぼ、デファクト・スタンダード（AzureやAWSのIdP/STSでもサポートされる）になっており、今後、SAML2.0から企業向けのFederated identityの標準を奪うと言う可能性もあります。

　...と言う事を考えると、クラウド & モバイルへの継続的な進出を念頭に置かれているならば、OAuth2.0の派生プロトコル群の継続的な利用を検討すべきかと思います。