OAuth2 / OpenID Connect課題解決備忘録 5

2018/06/18	OAuth2 / OpenID Connect課題解決備忘録 5	\| by nishino

　前回に続き、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を実装する必然性は殆どありません（外部ログイン + ユーザストアで良い）。