開発基盤部会 Blog

開発基盤部会 Blog >> 記事詳細

2018/06/18

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

Tweet ThisSend to Facebook | 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を実装する必然性は殆どありません(外部ログイン + ユーザストアで良い)。

<参考>

OpenID / OAuth / OpenID Connect - マイクロソフト系技術情報 Wiki
https://techinfoofmicrosofttech.osscons.jp/index.php?OpenID%20%2F%20OAuth%20%2F%20OpenID%20Connect
09:00 | 投票する | 投票数(0) | コメント(0) | ご報告