- 追加された行はこの色です。
- 削除された行はこの色です。
「[[マイクロソフト系技術情報 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]
***SSO(Single Sign-On)をサポートする。 [#g6a5175e]
-基本的に、
--[[OpenID Connect]]
--[[OAuth]] 2.0のBearer Tokenの[[JWT]]化
>が必要。
-スマホ認証の場合は、[[OAuth PKCE]]が必要。
***認証 / 認可フレームワーク [#u480f8e2]
***認証 / 認可フレームワークをサポートする。 [#u480f8e2]
-認証 / 認可フレームワークとはなにか?
-このフレームワーク中で[[各登場人物>#w20e53f4]]はどのようなロールを担うか?
***(Web)APIエコノミーのサポート [#l209c71d]
***(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/
>以前の投稿(第2回)で認証対象がユーザだった場合。
***[[サーバ信頼セキュリティ モデル]](例外) [#j8f27ea8]
-参考
--第2回(2018/05/21予定)~
https://www.osscons.jp/joyyxnads-537/
>何故かエンプラで採用の多い、Client Credentialsグラント種別
***スマホの場合 [#fb9f4ab1]
-参考
--第3回(2018/05/28予定)~
https://www.osscons.jp/jouqhleqc-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/
>パッケージに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]]をサポートしない。
-このため、既定の実装では、安全な認証や、SPA、スマホへの露出ができない。
-このため、既定の実装では、より安全な認証 / 認可や、スマホ・ネイティブへの露出ができない。
**[[ASP.NET Core Identity]](3系)版では、脱[[Community STS>ASP.NET Identity の Community STS]]した。[#id2a9c8d]
***概要 [#x6f056bb]
[[ASP.NET Core Identity]](3系)版の汎用認証サイトでは、諸事情により、
脱[[Community STS>ASP.NET Identity の Community STS]]した。
***参考 [#cde8b2c4]
-OSSコンソーシアム
--汎用認証サイトのASP.NET Core化について~
https://www.osscons.jp/jorgwf57r-537
--汎用認証サイト ASP.NET Core版の実装が完了しました。~
https://www.osscons.jp/jo4cm3lif-537
*参考 [#cb9c0a10]
説明に使用した図。~
※ 説明しながら伝導活動の重要性を感じた次第です。
**説明に使用した図 [#x46c43a4]
説明しながら伝導活動の重要性を感じた次第です。
#ref(temp.png,left,nowrap,OAuth / OpenID Connectによる課題解決)
**OSSC > 開発基盤部会 Blog [#n4dc7596]
***課題解決 [#yc33359f]
-OAuth / OpenID Connectによる課題解決~
https://www.osscons.jp/jo879cthe-537/
***備忘録 [#t2724a14]
-OAuth2 / OpenID Connect課題解決 備忘録
--第1回~
https://www.osscons.jp/joab17h5n-537/~
独自認証と、OAuth2 / OpenID Connectのプロトコル群
--第2回~
https://www.osscons.jp/joyyxnads-537/~
何故かエンプラで採用の多い、Client Credentialsグラント種別
--第3回~
https://www.osscons.jp/jouqhleqc-537/~
PKCEをサポートしない場合Client側で疑似PKCEする。
--第4回~
https://www.osscons.jp/jozpnvi15-537/~
以前の投稿(第2回)で認証対象がユーザだった場合。
--第5回~
https://www.osscons.jp/joq7suwpb-537/~
パッケージにIdP/STSを組み込もうとしてしまう現象について。
--第6回~
https://www.osscons.jp/jovzty1xk-537/~
SMSからのアクセス時の簡易的な認証方法について。
***[[PKCE 4 SPA>Authorization Code Grant Flow with PKCE#wdf47692]] [#sc1d5472]
***[[PPID>PPID#bf8c23c0]] [#db894fe7]
***[[Financial API>Financial API (FAPI)#t5a7240c]] [#gd7afccf]
***[[CIBA>CIBA(Client Initiated Backchannel Authentication)#m4873357]] [#faf4601a]
***[[IdP/STS 自作>https://opentouryo.osscons.jp/index.php?%E6%B1%8E%E7%94%A8%E8%AA%8D%E8%A8%BC%E3%82%B5%E3%82%A4%E3%83%88%EF%BC%88Multi-purpose%20Authentication%20Site%EF%BC%89#o4ba2456]] [#c865b4f0]
[[SAML]]2, [[FIDO]]等を含む。
***その他 [#h805fd31]
-オレオレPKCE実装とマイクロサービスやクラウドネイティブ開発の浸透~
https://www.osscons.jp/jom4szpyu-537/
-話題になったIdP/Stsの実装パターン、~
ASP.NET Identityが結構、参考になる。~
https://www.osscons.jp/jos8ktrsk-537/
-PKCEのトークンリクエストはフロントエンドから?バックエンドから?
--①~
https://www.osscons.jp/jorfs4g6d-537/
--②~
https://www.osscons.jp/joxql6yjz-537/
-クラウドネイティブ開発の浸透と、トークン・チェックのカスタマイズ~
https://www.osscons.jp/jospv68kt-537/
----
Tags: [[:認証基盤]], [[:クレームベース認証]], [[:OAuth]]
Tags: [[:IT国際標準]], [[:認証基盤]], [[:クレームベース認証]], [[:OAuth]]