前回に続き、OAuth2 / OpenID Connect課題解決 備忘録の第5回です。

　今回のテーマは、
　　「パッケージにIdP/STSを組み込もうとしてしまう現象について。」
　です。

＜組み込みたくなる理由＞

やはり、
・ イニシアティブの獲得
・ 受注価格の増額
　・ フィーの増額
　・ 構築費用の増額
だと思います。

気持ちは解ります。

＜推奨しない理由＞

しかし、以下の理由で推奨しません。

・ IdP/STS実装は専門性が高い。

　・ 実装量が多く、維持/保守できなくなる可能性がある。

　　・ 適切なIdP実装
　　　・ E-mailアドレス確認
　　　・ パスワード・リセット
　　　・ アカウント・ロックアウト
　　　・ SecurityStamp
　　　・ 2要素認証
　　　・ 適切なPasswordHash実装

　　・ 適切なSTS実装
　　　・ OAuth2
　　　・ OAuth2拡張
　　　・ OpenID Connect
　　　・ Financial-API

　　・GDPR（EU一般データ保護規則）への対応などが求められる。

　・ 正しい認証フローの選択 / 実装が難しい。
　　・ Resource Owner Password Credential は過渡期の代替案。
　　・ スマホならPKCEフロー、時としてHybrid フローの選択。
　　・ サーバー信頼セキュリティ モデルなら、
　　　JWT bearer token authorizationグラント種別

　・ 外部Login、Hybrid-IdPの提案と、その利用。

・ ビジネス・ アプリケーション・パッケージに
　IdP/STSを組込むと、顧客のためにならないことがある。

　・ SSOが既定となりつつある昨今、パッケージのユーザ・ストアは、
　　認証用ストアではなく、アプリケーション属性用ストアであるべき。
　・ WebAPIサポートが目的なら、 Token発行機能は必須ではなく、
　　WebAPIでTokenを検証するだけで良い（IdP/STSを組込む必要は無い）。

　・ IdP/STSが分割された場合、Login Sessionも分割され、
　　結果として、SSOが成立しなくなる。
　・ 業務パッケージAが業務パッケージBの認証機能に依存する。
　　...などと言った、歪な構成になる。

　・ パッケージ・ベンダ間で主導権争いになり適切な提案にならない。

＜結論＞

　ビジネス・アプリケーション・パッケージ側は、顧客要件を考慮した上で、適切な、IdP/STSを選択・利用するスキルが必要になると考えます。
　※ Hybrid-IdPとするのも一つの手かもしれませんが、パッケージ側を実装する難易度は上がりますし、パッケージ側でSTSを実装する必然性は殆どありません（外部ログイン + ユーザストアで良い）。

＜参考＞

OpenID / OAuth / OpenID Connect - マイクロソフト系技術情報 Wiki
https://techinfoofmicrosofttech.osscons.jp/index.php?OpenID%20%2F%20OAuth%20%2F%20OpenID%20Connect