OAuth / OpenID Connectによる課題解決のバックアップ(No.2)

「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

戻る

目次 †

↑

概要 †

OAuth / OpenID Connectの課題解決ノウハウをまとめています。

説明を始めると、
「単に「ユーザストアでアプリが認証する。」ということではない。」

というトコロからの説明が必要になります。

↑

導入 †

↑

要件の確認 †

↑

SSO（Single Sign-On）のサポート †

基本的に、

OpenID Connect
OAuth 2.0のBearer TokenのJWT化

が必要。

スマホ認証の場合は、OAuth PKCEが必要。

↑

認証 / 認可フレームワーク †

認証 / 認可フレームワークとはなにか？
フレームワーク中で各登場人物はどのようなロールを担うか？

↑

（Web）APIエコノミーのサポート †

システム間を連携させるAPI(Application Programing Interface)を通じて、
既存のサービスやデータをつなぎ、新たなビジネスや価値を生み出す仕組み。

認証連携とシステム間連系
SPA、スマホへの露出
管理の一元化（API Gatewayの導入）

↑

4つの登場人物 †

「OAuth2の4つの登場人物」についての説明が必要。

↑

Resource Owner †

ユーザー

↑

Authorization Server †

認証 / 認可の根幹となる機能を提供するプログラム。

↑

Resource Server †

Authorization Serverに対応したWebAPIを提供するプログラム。

↑

Client †

上記の認証基盤を使用してWebAPIにアクセスするプログラム。

↑

詳細 †

↑

クロスプラットフォーム & コンパチブル †

オープンなプロトコルを使用しているため、
クロスプラットフォーム対応可能であること。

故に、4つの登場人物がプラットフォームや言語に依存せず、
クロスプラットフォーム & コンパチブルであることが求められる。

↑

Authorization Serverからの視点 †

Authorization Server提供者は、

様々なユーザストアに対応する必要がある。
OAuth 2.0のBearer TokenのJWT化が必要。
OAuth 2.0拡張 / OpenID Connectのサポートについて検討が必要。

↑

Resource Serverからの視点 †

Resource Server提供者は、

様々なAuthorization Serverと連携可能な提案を行う必要がある。

従って、Tokenの検証方法を検討する必要がある
- JWT -> JWSの署名検証
- OAuth 2.0 Token Introspection

上記２つをまとめて解決する、API Gatewayの導入を検討しても良い。

↑

Clientからの視点 †

Client提供者は、

使用するAuthorization Server、Resource Serverを選択する。
この場合、サポートされるFlowやTokenのフォーマットを理解する必要がある。

↑

ASP.NET Identityの生の実装ダケではダメ †

ASP.NET Identityを使うダケで頑張れるか？と言えばそんなこともありません。

↑

カスタマイズ †

ASP.NET Identityを覚えるダケでも、ある程度、大変ですが、
更に、IdP & STSは、カスタマイズが必要となるケースが多い。

↑

Bearer Token †

また、ASP.NET IdentityのBearer Tokenは、ASP.NET Identityしか理解しないので、
他のプラットフォームや言語で処理可能なようにJWT化が必要になってくる。

↑

プロトコル †

生のASP.NET Identityは、OAuth 2.0拡張 / OpenID Connectをサポートしない。
このため、既定の実装では、安全な認証や、SPA、スマホへの露出ができない。

↑

参考 †

説明に使用した図。
※ 説明しながら伝導活動の重要性を感じた次第です。

Tags: :認証基盤, :クレームベース認証, :OAuth

OAuth / OpenID Connectによる課題解決 のバックアップ(No.2)