「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。 -[[戻る>OpenID / OAuth / OpenID Connect]] * 目次 [#j5ff9e92] #contents *概要 [#sbb490d1] -[[OAuth]] / [[OpenID Connect]]の課題解決ノウハウをまとめています。 -説明を始めると、 >「単に「ユーザストアを使ってアプリを認証する。」ということではない。」 >というトコロからの説明が必要になります。 *導入 [#m4c226b6] **要件の確認 [#n410df59] ***SSO(Single Sign-On)をサポートする。 [#g6a5175e] -基本的に、 --[[OpenID Connect]] --[[OAuth]] 2.0のBearer Tokenの[[JWT]]化 >が必要。 -スマホ認証の場合は、[[OAuth PKCE]]が必要。 ***認証 / 認可フレームワークをサポートする。 [#u480f8e2] -認証 / 認可フレームワークとはなにか? -このフレームワーク中で[[各登場人物>#w20e53f4]]はどのようなロールを担うか? ***(Web)APIエコノミーをサポートする。 [#l209c71d] システム間を連携させるAPI(Application Programing Interface)を通じて、~ 既存のサービスやデータをつなぎ、新たなビジネスや価値を生み出す仕組み。 -認証連携とシステム間連系 -[[SPA、スマホへの露出>UserAgentでOAuth2のTokenを取得するベスト・プラクティス]] -管理の一元化([[API Gateway]]の導入) ***ID連携、IDフェデレーション、Federated identityをサポートする。 [#jd120c46] -認証用のユーザストアと属性格納用のユーザストアを分離できる。 -これにより、認証基盤の、 --セキュリティ・レベル --ITガバナンス >を維持しつつ、アプリケーション、サービス側で、柔軟な対応をとることができる。 **4つの登場人物 [#w20e53f4] 「[[OAuth2の4つの登場人物>OAuth#zb38b595]]」についての説明が必要。 ***Resource Owner [#ue54d411] 認証 / 認可を行うユーザー -[[Authorization Server>#x2b3bde9]]にサインインすることで認証される。 -[[Client>#rd84ff2c]]が要求する認可を[[Authorization Server>#x2b3bde9]]上で許可することでtokenが発行される。 ***Authorization Server [#x2b3bde9] 認証 / 認可の根幹となる機能を提供するプログラム。 -IdPとSTSから構成される。 --IdP ---Identity Provider ---サインアップ、サインイン・サインアウトの機能を提供。 --STS ---Security Token Service ---サインイン(認証)した[[ユーザ(Resource Owner)>#ue54d411]]と認可された範囲を示すtokenを発行する。 ***Resource Server [#bf1f74a5] [[Authorization Server>#x2b3bde9]]に対応したWebAPIを提供するプログラム。 -認証された[[ユーザ(Resource Owner)>#ue54d411]]に、認可された範囲の処理・データを提供する。 ***Client [#rd84ff2c] [[Authorization Server>#x2b3bde9]]を使用して[[Resource Server>#bf1f74a5]]のWebAPIにアクセスするプログラム。 -Clientが、[[Authorization Server>#x2b3bde9]]にtokenを要求すると、~ [[ユーザ(Resource Owner)>#ue54d411]]がサインイン(認証)・認可したtokenを受け取る。 -Clientは、このtokenを使用して、[[Resource Server>#bf1f74a5]]のWebAPIにアクセスする。 **適切なフローの選択 [#nddd8c88] ***[[ベース クライアント セキュリティ モデル]](基本) [#i8267ff1] -参考 --第4回(2018/06/11予定)~ https://www.osscons.jp/jozpnvi15-537/#_537 >以前の投稿(第2回)で認証対象がユーザだった場合。 ***[[サーバ信頼セキュリティ モデル]](例外) [#j8f27ea8] -参考 --第2回(2018/05/21予定)~ https://www.osscons.jp/joyyxnads-537/#_537 >何故かエンプラで採用の多い、Client Credentialsグラント種別 ***スマホの場合 [#fb9f4ab1] -参考 --第3回(2018/05/28予定)~ https://www.osscons.jp/jouqhleqc-537/#_537 >PKCEをサポートしない場合Client側で疑似PKCEする。 **よくある誤解 [#y3175bbc] ***Cookie認証チケットとAccessTokenの違い [#l1fa44ae] -Cookie認証チケット --ログインは通常、Cookie認証チケットによって形成される「ログイン・セッション」に依存する。 --以下の2つの「ログイン・セッション」を別々に認識する必要がある。 ---Authorization Server側のCookie認証チケットによるログイン・セッション ---Client側のCookie認証チケットによるログイン・セッション -AccessToken~ AccessTokenはあくまで、 --IdPで認証できたという結果をうけて --STSが生成・通知するtokenなので、 >上記の2つのCookie認証チケットとは別物になる。 ***パッケージに、IdP/STSを組み込んだら上手くいく。 [#w2fe7e33] -OSSコンソーシアム --OAuth2 / OpenID Connect課題解決 備忘録 5(2018/06/18予定)~~ https://www.osscons.jp/joq7suwpb-537/#_537 >パッケージにIdP/STSを組み込もうとしてしまう現象について。 *詳細 [#wd05a75f] **そもそも認証から(IdP単品) [#r28f192d] ***IdPの機能をフルサポートするのは大変 [#d0e8c848] [[コチラ>ASP.NET Identity]]が参考になる。 ***STSにより、独自ユーザストアから全社認証基盤へ。 [#cf4a035b] -システムやパッケージに独自ユーザストアを持つのは、~ 非効率、且つ、セキュリティ的にも脆弱になり易いという問題を持つ。 -IdPに、[[OAuth]] / [[OpenID Connect]]などのSTS機能を搭載すれば、~ SSO(Single Sign-On)によって、この問題を解決できる。 **クロスプラットフォーム & コンパチブル [#r3e76c2d] -オープンなプロトコルを使用しているため、~ クロスプラットフォーム対応可能であること。 -故に、4つの登場人物がプラットフォームや言語に依存せず、~ クロスプラットフォーム & コンパチブルであることが求められる。 ***Authorization Serverからの視点 [#j163495b] Authorization Server提供者は、 -様々なユーザストアに対応する必要がある。 -[[OAuth]] 2.0のBearer Tokenの[[JWT]]化が必要。 -[[OAuth]] 2.0拡張 / [[OpenID Connect]]のサポートについて検討が必要。 ***Resource Serverからの視点 [#z6ae8ab9] Resource Server提供者は、 -様々なAuthorization Serverと連携可能な提案を行う必要がある。 -従って、Tokenの検証方法を検討する必要がある --[[JWT]] -> [[JWS]]の署名検証 --[[OAuth 2.0 Token Introspection]] -上記2つをまとめて解決する、[[API Gateway]]の導入を検討しても良い。 ***Clientからの視点 [#m1423689] Client提供者は、 -使用するAuthorization Server、Resource Serverを選択する。 -この場合、サポートされるFlowやTokenのフォーマットを理解する必要がある。 **IDフェデレーションの段階 [#ydf65f2c] 以下の、3つの段階がある。 ***Single [#ua3f3ad0] Client *--- IdP (Authorization Server) -IdPのみユーザストアを持つ。~ Clientは、 --認証結果のClaimをAuthorization Serverから受け取り、 --認証済みの処理を行う。 -IdPとClientがユーザストアを持つ。~ Clientは、 --認証結果のClaimをAuthorization Serverから受け取り、 --Claimをユーザストアに格納し、 --そこに補足的ユーザ属性を加え、 --認証済みの処理を行う。 ***Hybrid [#pd46d644] Hybrid-IdP (Client *--- IdP2 *--- IdP1) -IdP1とIdP2がユーザストアを持つ。~ Clientから要求を受けた、Authorization Server1は、 --認証結果のClaimをAuthorization Server2から受け取り、 --ClaimをAuthorization Server1のユーザストアに格納し、 --そこに補足的ユーザ属性を加え、 --次いで、要求元のClientに、認証結果のClaimを返す。 --最後に、Clientは、認証済みの処理を行う。 -ClientとIdP1とIdP2がユーザストアを持つ。~ Clientから要求を受けた、Authorization Server1は、 --認証結果のClaimをAuthorization Server2から受け取り、 --ClaimをAuthorization Server1のユーザストアに格納し、 --そこに補足的ユーザ属性を加え、 --次いで、要求元のClientに、認証結果のClaimを返す。 --Clientは ---Claimをユーザストアに格納し、 ---そこに補足的ユーザ属性を加え、 ---認証済みの処理を行う。 >※ 認証はAuthorization Server2で、属性編集はAuthorization Server1で可能。 *@.net [#jf1ed855] **[[ASP.NET Identity]](2系)の生の実装ダケではダメ [#o71994b3] [[ASP.NET Identity]](2系)を使うダケで頑張れるか?と言えばそんなこともありません。 ***カスタマイズ [#g952bfed] [[ASP.NET Identity]](2系)を覚えるダケでも、ある程度、大変ですが、~ 更に、IdP & STSは、カスタマイズが必要となるケースが多い。 ***Bearer Token [#hc89dbc7] -また、[[ASP.NET Identity]](2系)のBearer Tokenは、[[ASP.NET Identity]]しか理解しないので、 -他のプラットフォームや言語で処理可能なように[[JWT化>JWTとOAuth2.0#k0b22c52]]が必要になってくる。 ***プロトコル [#kba6cccb] -生の[[ASP.NET Identity]](2系)は、[[OAuth]] 2.0拡張 / [[OpenID Connect]]をサポートしない。 -このため、既定の実装では、より安全な認証 / 認可や、スマホ・ネイティブへの露出ができない。 *参考 [#cb9c0a10] **説明に使用した図 [#x46c43a4] 説明しながら伝導活動の重要性を感じた次第です。 #ref(temp.png,left,nowrap,OAuth / OpenID Connectによる課題解決) **OSSコンソーシアム [#n4dc7596] ***課題解決 [#yc33359f] -OAuth / OpenID Connectによる課題解決~ https://www.osscons.jp/jo879cthe-537/#_537 ***備忘録 [#t2724a14] -OAuth2 / OpenID Connect課題解決 備忘録 --第1回~ https://www.osscons.jp/joab17h5n-537/#_537 >独自認証と、OAuth2 / OpenID Connectのプロトコル群 --第2回~ https://www.osscons.jp/joyyxnads-537/#_537 >何故かエンプラで採用の多い、Client Credentialsグラント種別 --第3回~ https://www.osscons.jp/jouqhleqc-537/#_537 >PKCEをサポートしない場合Client側で疑似PKCEする。 --第4回~ https://www.osscons.jp/jozpnvi15-537/#_537 >以前の投稿(第2回)で認証対象がユーザだった場合。 --第5回~ https://www.osscons.jp/joq7suwpb-537/#_537 >パッケージにIdP/STSを組み込もうとしてしまう現象について。 --第6回~ https://www.osscons.jp/jovzty1xk-537/#_537 >SMSからのアクセス時の簡易的な認証方法について。 ---- Tags: [[:認証基盤]], [[:クレームベース認証]], [[:OAuth]]