認証を調べる

3 分

認証とは、ID (ユーザー、アプリ、またはデバイス) が、それが宣言しているとおりのものであることを検証することです。その場合、認証トランザクション全体を通じて適切なレベルの検証とセキュリティも提供されます。 ID 認証では、次の機能が提供されます。

組織間を統合する柔軟で標準に準拠した認証
さまざまなソース、アプリケーション、プロトコルの統合
多くのさまざまな業界標準の検証と保証の方法の導入

認証に ID プロバイダーを使うと、ユーザーの機能を制限することなく、セキュリティで保護された ID を保証する方法が提供されます。利便性、ID を検証するための複数のソース、業界のプロトコル、および ID の保証が得られます。

利便性 - 利便性機能で重視されているのは、認証資格情報の要求方法を含むエンドユーザーのエクスペリエンスです。ここでの焦点はエンドユーザーエクスペリエンスです。簡単でないものがあると、ユーザーはそれを避けたり、それについて不平を言ったりします。

ソース - ソース機能の中心になるのは、ユーザーが認証トークンを取得する場所です。多くの組織は発行元 (Microsoft Entra ID) が一元化されていると信じていますが、実際には、ほとんどの組織には他にも ID リポジトリがあります。フェデレーション ID は、最も一般的な他の ID プロバイダーです。

プロトコル - 多くの場合、組織にはさまざまな認証プロトコルが存在し、これはエンドユーザーと組織の両方にとって問題のあるエクスペリエンスの原因となります。この機能で重要なのは、組織が 1 つの、またはよりいっそう、最新でセキュリティ保護された認証プロトコルに標準化して、認証の目標を達成できるようにすることです。

保証 - 認証の保証とは、リソースにアクセスする個人が自分で言うとおりの人であることに対する、組織の信頼です。この能力は、組織が共有アカウントを使用しているかどうか、カスタマイズされたアカウントを使用しているかどうか、および多要素認証やリスクベースの認証などのソリューションが存在しているかどうかに関するものです。

フェデレーション ID

フェデレーションとは、信頼が確立されたドメインのコレクションのことです。信頼のレベルはさまざまですが、通常は認証を含み、ほとんどの場合、認可を含みます。このフェデレーションにより、既存のオンプレミスの Active Directory など、信頼されたソースの既存の ID を適用できます。

ID での一般的な通信プロトコル

Protocol	説明と使用方法
SAML - Security Assertion Markup Language	ID プロバイダーとサービスプロバイダー間で認証および認可データを交換するためのオープン標準。 SAML の一般的な属性:
	プリンシパル = 一般にユーザーまたはデバイス、IdP = ID プロバイダー、SP = サービスプロバイダー
	IdP = ID プロバイダー
	SP = サービスプロバイダー
WS-Fed - Web Services Federation	外部の ID 交換と認証を介してシングルサインオンを提供するための、Web サービスセキュリティフレームワークの ID 仕様。
OIDC - OpenID Connect	OIDC は、OAuth を使ってシングルサインオンできるよう、OAuth 2.0 承認プロトコルを認証プロトコルとして使用するように拡張します。

OpenID Connect

OpenID Connect (OIDC) は、OAuth 2.0 を基盤にした認証プロトコルです。このプロトコルにより、ユーザーをアプリケーションに安全にサインインさせることができます。 Microsoft ID プラットフォームによる OpenID Connect の実装を使用すると、サインインおよび API アクセスをアプリに追加できます。 OpenID Connect は、OAuth 2.0 承認プロトコルを認証プロトコルとして使用するために拡張したものです。これにより、OAuth を使用したシングルサインオンを行うことができます。 OpenID Connect には、ID トークンの概念が導入されています。ID トークンとは、クライアントがユーザーの本人性を確認できるセキュリティトークンです。 ID トークンは、ユーザーに関する基本的なプロファイル情報も取得します。また、ユーザーに関する情報を返す API である、UserInfo エンドポイントが導入されています。

Microsoft Entra ID のクレームベースの ID

ユーザーがサインインすると、Microsoft Entra ID は、ユーザーに関する要求セットを含む ID トークンを送信します。要求は、キーと値のペアで表される 1 つの情報です。たとえば、bob@contoso.com のようなものです。クレームには、ユーザーを認証し、クレームを作成するエンティティである発行者 (この場合は Microsoft Entra ID) が含まれています。発行者は、ユーザーを認証し、要求を作成するエンティティです。発行者を信頼していれば、要求も信頼することになります(逆に、信頼できない発行者の場合は、要求も信頼しないでください)。

概要:

ユーザーを認証します。
ID プロバイダー (IDP) は、一連の要求を送信します。
アプリで、要求の正規化または強化が行われます (省略可能)。
アプリで、要求を使用して承認が決定されます。

OpenID Connect では、取得する要求のセットは、認証要求のスコープパラメーターによって制御されます。ただし、Microsoft Entra ID がセキュリティトークン (主に JSON Web Token が使われます) を使って OpenID Connect を介して発行するクレームのセットは限られています。ユーザーの詳細情報が必要な場合は、Graph API と Microsoft Entra ID を使用する必要があります。

セキュリティトークン

Microsoft ID プラットフォームではユーザーを認証し、セキュリティトークン (アクセストークン、リフレッシュトークン、ID トークンなど) を提供します。セキュリティトークンを使用すると、クライアントアプリケーションは、リソースサーバー上の保護されたリソースにアクセスできます。トークンの一般的な種類は、アクセストークン、更新トークン、ID トークンの 3 つです。

アクセストークン - アクセストークンは、OAuth 2.0 フローの一部として承認サーバーによって発行されるセキュリティトークンです。これには、そのトークンの対象となるユーザーとリソースに関する情報が含まれています。この情報を使用すると、Web API やその他の保護されたリソースにアクセスできます。アクセストークンは、クライアントアプリにアクセス権を付与するためにリソースによって検証されます。 Microsoft ID プラットフォームがアクセストークンを発行する方法の詳細については、アクセストークンに関するページを参照してください。
更新トークン - アクセストークンは短時間しか有効でないため、承認サーバーでは、アクセストークンが発行されると同時に更新トークンを発行する場合があります。クライアントアプリケーションでは、必要に応じて、このリフレッシュトークンを新しいアクセストークンに交換できます。 Microsoft ID プラットフォームが更新トークンを使用してアクセス許可を取り消す方法の詳細については、「トークンの失効」を参照してください。
ID トークン - ID トークンは、OpenID Connect フローの一部としてクライアントアプリケーションに送信されます。これらは、アクセストークンの代わりに、またはアクセストークンと共に送信できます。 ID トークンは、ユーザーを認証するためにクライアントによって使用されます。 Microsoft ID プラットフォームが ID トークンを発行する方法の詳細については、ID トークンに関するページを参照してください。

JSON Web Token (JWT) とは

JSON Web Token (JWT) はオープン標準 (RFC 7519) であり、パーティー間で情報を JSON オブジェクトとして安全に送信するためのコンパクトで自己完結型の方法が定義されています。この情報はデジタル署名されているため、検証して信頼することができます。 JWT の署名には、シークレットを使用するか、公開/秘密キーの組を使用します。 JWT を暗号化してパーティー間の機密性を提供することもできますが、ここでは署名付きトークンに焦点を当てます。署名済みトークンはその中に含まれるクレームの整合性を検証できますが、暗号化されたトークンは他のパーティーからそれらのクレームを隠します。公開キーと秘密キーのペアを使ってトークンが署名されている場合、署名は秘密キーを持っているパーティのみが署名したパーティーであることも証明します。

注意

JWT の Web サイトから提供される情報 - https://jwt.io/。

クレームベースの ID 内の定義

Microsoft Entra ID でのクレームベースの ID について説明するときに使われる一般的な用語がいくつかあります。

クレーム - セキュリティトークン内のデータの値ペア。トークン内では、トークンの種類を定義するクレームから暗号化方法に関するものまで、複数のクレームが転送されます。次の例を示します:
```
   Header
   {
     "alg": "HS256",
     "typ": "JWT"
   }
   Content payload
   {
     "sub": "1234567890",
     "name": "John Doe",
     "aud": "https://jwt.io"
   }
```
アサーション - セキュリティドメイン間でユーザーまたはアカウントに関する ID とセキュリティ情報を共有する、通常はトークンの形式のデータのパッケージ。
属性 - トークン内のデータの値ペア。
拡張 - ユーザーに関するさらなる詳細を提供するために、ユーザートークンに他の要求を追加するプロセス。これには、人事 (HR) システム、SharePoint などのアプリケーション、他のシステムからのデータが含まれる場合があります。

続行