タイトルにある「オレオレPKCE」というのは、某案件で、昔のverの「汎用認証サイト」がOAuth PKCEをサポートしてなかったのでリプレースを提案したら、「予算・期間・人的資源的に難かしい。」と言われてしまったので、取り敢えず、Client側に実装を足して、PKCEッポくしたと言う話です（以下、その処理シーケンスです）。


　マイクロサービスやクラウドネイティブなどのアプリケーション開発、SI案件では、まだまだ稀な気がしますが、今後、徐々に増えていくのではないか？等と、この手の導入事例を経験したことで考えていて、この手のterm、昔のSOA的なbuzzwordッポさを含有しつつ、本質的面も含んでいる気がします。

　当該案件の PM / PL、若手で、認証系は知らないようでしたが、飲み込みも早い（逆に、某弊 "開発基盤部会" は飲み込ませるのが上手い。とも言える）。認証系も、サプライサイドが出し惜しんでないで点火すれば、一気に広がる感はあります。以下の様に、SIerの中でも脱 "労働集型産業" の準備は着々と進んでいるように思います（？）。


　こう言う点を考えると、「サプライサイドの弱点は、プロダクトでマネタイズしないといけない。」と言うトコロだろうと思いますが、この辺、前回も書きましたが、「プロダクトは複数のデマンドサイドの企業が、開発・維持 / 保守して行くようになるンじゃないか？」なんて考えています。

　また、この辺や、この辺で、「担ぐ系」（のサプライサイド）の問題を書きましたが、例えば、プロダクトを担いで認証ソリューションをやっている場合、プロダクトのレイヤから触っているだけだと、なかなか、上記の様な対応はできないんじゃないか？などと思ったりしています。

　例えば、オープンソース & 認証界隈で有名な某SSTech社等は、プロトコル・レベルで、SAML, OAuth / OIDC等を把握して、OSS自体をカスタマイズする能力も持っているように思います。確かに、ココ迄のレベルに到達しないと、例えば、Active Directoryのフェデレーション・サービス（ADFS）などの既製品を "担いだ" 場合、導入が容易であるというメリットがありますが、同時に当該製品がサポートする範囲の構築しかできず、自由に振り回すことが出来ないため、差別化が困難であると言うデメリットがあります。

　そういう意味で、サプライサイド単体での「製品開発 + 構築ソリューション」や、「既製品 + 構築ソリューション」などは厳しくなっていて、昨今、プロダクトの開発・維持 / 保守は、（収益性の高い）デマンドサイドに支えられるようになってきているのだと思います。...と言うか、よくよく考えると、垂直統合事業の場合、プロダクト単体でマネタイズしている体ですが、実際のトコロ、昔から、デマンドサイドに支えられていましたね。

　そして、昨今の問題は、


　でしょうか。

　こうなって来ると、
　垂直統合な事業は、
　非常に厳しいですね。