あなたの .NET Core (Blazor WASM) アプリケーションに認証 (Authentication) を追加する

ヒント:

以下のデモンストレーションは、.NET Core 8.0 と Blorc.OpenIdConnect に基づいて構築されています。
.NET Core のサンプルプロジェクトは GitHub リポジトリで入手可能です。

前提条件

Logto Cloud アカウントまたはセルフホスト Logto。
Logto シングルページアプリケーションが作成されていること。

インストール

プロジェクトに NuGet パッケージを追加します：

dotnet add package Blorc.OpenIdConnect

統合

スクリプト参照を追加する

index.html ファイルに Blorc.Core/injector.js を含めます：

index.html
<head>
  <!-- ... -->
  <script src="_content/Blorc.Core/injector.js"></script>
  <!-- ... -->
</head>

サービスを登録する

次のコードを Program.cs ファイルに追加します：

Program.cs
using Blorc.OpenIdConnect;
using Blorc.Services;

builder.Services.AddBlorcCore();
builder.Services.AddAuthorizationCore();
builder.Services.AddBlorcOpenIdConnect(
    options =>
    {
        builder.Configuration.Bind("IdentityServer", options);
    });

var webAssemblyHost = builder.Build();

await webAssemblyHost
    .ConfigureDocumentAsync(async documentService =>
    {
        await documentService.InjectBlorcCoreJsAsync();
        await documentService.InjectOpenIdConnectAsync();
    });

await webAssemblyHost.RunAsync();

備考:

Microsoft.AspNetCore.Components.WebAssembly.Authentication パッケージを使用する必要はありません。Blorc.OpenIdConnect パッケージが認証 (Authentication) プロセスを処理します。

リダイレクト URI を設定する

詳細に入る前に、エンドユーザーの体験について簡単に説明します。サインインプロセスは次のように簡略化できます：

あなたのアプリがサインインメソッドを呼び出します。
ユーザーは Logto のサインインページにリダイレクトされます。ネイティブアプリの場合、システムブラウザが開かれます。
ユーザーがサインインし、あなたのアプリにリダイレクトされます（リダイレクト URI として設定されています）。

リダイレクトベースのサインインについて

この認証 (Authentication) プロセスは OpenID Connect (OIDC) プロトコルに従い、Logto はユーザーのサインインを保護するために厳格なセキュリティ対策を講じています。
複数のアプリがある場合、同じアイデンティティプロバイダー (Logto) を使用できます。ユーザーがあるアプリにサインインすると、Logto は別のアプリにアクセスした際に自動的にサインインプロセスを完了します。

リダイレクトベースのサインインの理論と利点について詳しく知るには、Logto サインイン体験の説明を参照してください。

注記:

以下のコードスニペットでは、あなたのアプリが http://localhost:3000/ で実行されていると仮定しています。

リダイレクト URI を設定する

Logto Console のアプリケーション詳細ページに移動します。リダイレクト URI http://localhost:3000/callback を追加します。

サインインと同様に、ユーザーは共有セッションからサインアウトするために Logto にリダイレクトされるべきです。完了したら、ユーザーをあなたのウェブサイトに戻すと良いでしょう。例えば、http://localhost:3000/ をサインアウト後のリダイレクト URI セクションとして追加します。

その後、「保存」をクリックして変更を保存します。

アプリケーションを設定する

次のコードを appsettings.json ファイルに追加します：

appsettings.json
{
// ...
IdentityServer: {
  Authority: 'https://<your-logto-endpoint>/oidc',
  ClientId: '<your-logto-app-id>',
  PostLogoutRedirectUri: 'http://localhost:3000/',
  RedirectUri: 'http://localhost:3000/callback',
  ResponseType: 'code',
  Scope: 'openid profile', // 必要に応じてスコープを追加
},
}

RedirectUri と PostLogoutRedirectUri を Logto アプリケーション設定の許可されたリダイレクト URI のリストに追加することを忘れないでください。これらはどちらも WASM アプリケーションの URL です。

`AuthorizeView` コンポーネントを追加する

認証 (Authentication) が必要な Razor ページに AuthorizeView コンポーネントを追加します。Home.razor ページであると仮定します：

Pages/Home.razor
@using Microsoft.AspNetCore.Components.Authorization
@page "/"

<AuthorizeView>
    <Authorized>
        @* サインイン済みビュー *@
        <button @onclick="OnLogoutButtonClickAsync">
            サインアウト
        </button>
    </Authorized>
    <NotAuthorized>
        @* 未認証ビュー *@
        <button @onclick="OnLoginButtonClickAsync">
            サインイン
        </button>
    </NotAuthorized>
</AuthorizeView>

認証 (Authentication) を設定する

Home.razor.cs ファイルに（存在しない場合は作成して）次のコードを追加します：

Pages/Home.razor.cs
using Microsoft.AspNetCore.Authorization;
using Microsoft.AspNetCore.Components;
using Microsoft.AspNetCore.Components.Web;
using Blorc.OpenIdConnect;
using Microsoft.AspNetCore.Components.Authorization;

[Authorize]
public partial class Home : ComponentBase
{
    [Inject]
    public required IUserManager UserManager { get; set; }

    public User<Profile>? User { get; set; }

    [CascadingParameter]
    protected Task<AuthenticationState>? AuthenticationStateTask { get; set; }

    protected override async Task OnInitializedAsync()
    {
        User = await UserManager.GetUserAsync<User<Profile>>(AuthenticationStateTask!);
    }

    private async Task OnLoginButtonClickAsync(MouseEventArgs obj)
    {
        await UserManager.SignInRedirectAsync();
    }

    private async Task OnLogoutButtonClickAsync(MouseEventArgs obj)
    {
        await UserManager.SignOutRedirectAsync();
    }
}

ユーザーが認証 (Authentication) されると、User プロパティにユーザー情報が設定されます。

チェックポイント: アプリケーションをテストする

これで、アプリケーションをテストできます：

アプリケーションを実行すると、サインインボタンが表示されます。
サインインボタンをクリックすると、SDK がサインインプロセスを初期化し、Logto のサインインページにリダイレクトされます。
サインインすると、アプリケーションに戻り、サインアウトボタンが表示されます。
サインアウトボタンをクリックしてローカルストレージをクリアし、サインアウトします。

ユーザー情報を取得する

ユーザー情報を表示する

Home.razor ページでユーザー情報を表示する方法の例をいくつか示します：

<AuthorizeView>
    <Authorized>
        @* サインイン済みビュー *@
        @* ... *@
        <p>あなたは @(@User?.Profile?.Name ?? "(unknown name)") としてサインインしています。</p>
    </Authorized>
    @* ... *@
</AuthorizeView>

より多くのプロパティとクレームについては、Blorc.OpenIdConnect パッケージの User と Profile クラスを確認してください。

追加のクレームをリクエストする

User から返されるオブジェクトに一部のユーザー情報が欠けていることがあります。これは、OAuth 2.0 と OpenID Connect (OIDC) が最小特権の原則 (PoLP) に従うように設計されており、Logto はこれらの標準に基づいて構築されているためです。

デフォルトでは、限られたクレーム (Claim) が返されます。より多くの情報が必要な場合は、追加のスコープ (Scope) をリクエストして、より多くのクレーム (Claim) にアクセスできます。

備考:

「クレーム (Claim)」はサブジェクトについての主張であり、「スコープ (Scope)」はクレーム (Claim) のグループです。現在のケースでは、クレーム (Claim) はユーザーに関する情報の一部です。

スコープ - クレーム (Claim) 関係の非規範的な例を示します：

ヒント:

「sub」クレーム (Claim) は「サブジェクト (Subject)」を意味し、ユーザーの一意の識別子（つまり、ユーザー ID）です。

Logto SDK は常に 3 つのスコープ (Scope) をリクエストします：openid、profile、および offline_access。

追加のスコープをリクエストするには、有効なスコープを appsettings.json ファイルの IdentityServer.Scope プロパティに追加できます。

{
  // ...
  "IdentityServer": {
    // ...
    "Scope": "openid profile email phone"
  }
}

ネットワークリクエストが必要なクレーム

ユーザーオブジェクトの肥大化を防ぐために、一部のクレームは取得するためにネットワークリクエストが必要です。例えば、custom_data クレームはスコープでリクエストされていてもユーザーオブジェクトには含まれません。これらのクレームを取得するには、appsettings.json ファイルで IdentityServer.LoadUserInfo プロパティを true に設定できます。

例えば、ユーザーのメールアドレスとカスタムデータを取得するには、次の設定を使用できます：

{
  // ...
  "IdentityServer": {
    // ...
    "Scope": "openid profile email custom_data",
    "LoadUserInfo": true
  }
}

スコープとクレーム

Logto は OIDC のスコープとクレームの規約を使用して、ID トークンおよび OIDC userinfo エンドポイントからユーザー情報を取得するためのスコープとクレームを定義します。「スコープ」と「クレーム」は、OAuth 2.0 および OpenID Connect (OIDC) 仕様からの用語です。

サポートされているスコープと対応するクレーム (Claims) のリストはこちらです：

openid

クレーム名	タイプ	説明	ユーザー情報が必要か？
sub	`string`	ユーザーの一意の識別子	いいえ

profile

クレーム名	タイプ	説明	ユーザー情報が必要か？
name	`string`	ユーザーのフルネーム	いいえ
username	`string`	ユーザーのユーザー名	いいえ
picture	`string`	エンドユーザーのプロフィール写真の URL。この URL は、画像を含む Web ページではなく、画像ファイル（例えば PNG、JPEG、または GIF 画像ファイル）を指す必要があります。この URL は、エンドユーザーを説明する際に表示するのに適したプロフィール写真を特に参照するべきであり、エンドユーザーが撮影した任意の写真を参照するべきではありません。	いいえ
created_at	`number`	エンドユーザーが作成された時間。時間は Unix エポック（1970-01-01T00:00:00Z）からのミリ秒数で表されます。	いいえ
updated_at	`number`	エンドユーザーの情報が最後に更新された時間。時間は Unix エポック（1970-01-01T00:00:00Z）からのミリ秒数で表されます。	いいえ

その他の標準クレームには、family_name、given_name、middle_name、nickname、preferred_username、profile、website、gender、birthdate、zoneinfo、および locale が含まれ、ユーザー情報エンドポイントを要求することなく profile スコープに含まれます。上記のクレームと異なる点は、これらのクレームは値が空でない場合にのみ返されることであり、上記のクレームは値が空の場合に null を返します。

注記:

標準クレームとは異なり、created_at と updated_at クレームは秒ではなくミリ秒を使用しています。

email

クレーム名	タイプ	説明	ユーザー情報が必要か？
email	`string`	ユーザーのメールアドレス	いいえ
email_verified	`boolean`	メールアドレスが確認済みかどうか	いいえ

phone

クレーム名	タイプ	説明	ユーザー情報が必要か？
phone_number	`string`	ユーザーの電話番号	いいえ
phone_number_verified	`boolean`	電話番号が確認済みかどうか	いいえ

address

住所クレームの詳細については、OpenID Connect Core 1.0 を参照してください。

custom_data

クレーム名	タイプ	説明	ユーザー情報が必要か？
custom_data	`object`	ユーザーのカスタムデータ	はい

identities

クレーム名	タイプ	説明	ユーザー情報が必要か？
identities	`object`	ユーザーのリンクされたアイデンティティ	はい
sso_identities	`array`	ユーザーのリンクされた SSO アイデンティティ	はい

urn:logto:scope:organizations

クレーム名	タイプ	説明	ユーザー情報が必要か？
organizations	`string[]`	ユーザーが所属する組織の ID	いいえ
organization_data	`object[]`	ユーザーが所属する組織のデータ	はい

urn:logto:scope:organization_roles

クレーム名	タイプ	説明	ユーザー情報が必要か？
organization_roles	`string[]`	ユーザーが所属する組織のロールで、`<organization_id>:<role_name>` の形式	いいえ

パフォーマンスとデータサイズを考慮して、「ユーザー情報が必要か？」が「はい」の場合、クレームは ID トークンに表示されず、ユーザー情報エンドポイントのレスポンスで返されます。

API リソース

まず 🔐 ロールベースのアクセス制御 (RBAC) を読むことをお勧めします。これにより、Logto の RBAC の基本概念と API リソースを適切に設定する方法を理解できます。

デフォルトでは、User?.AccessToken にアクセスすると、短い長さで JWT (JSON Web Token) ではない不透明トークン (不透明トークン) が取得されます。このトークンは userinfo エンドポイントにアクセスするために使用されます。

設定に API リソースを追加する

Logto で定義された API リソースにアクセスするために使用できる JWT トークンを取得するには、次のパラメーターを appsettings.json ファイルに追加します（https://my-api-resource を例として使用）：

appsettings.json
{
  // ...
  "IdentityServer": {
    // ...
    "Scope": "openid profile email <your-api-scopes>", // ここに API スコープを追加
    "Resource": "https://my-api-resource",
    "ExtraTokenParams": {
        "resource": "https://my-api-resource" // キー "resource" が小文字であることを確認
    }
  }
}

Resource プロパティは、認可リクエストに API リソースを追加するために使用されます。ExtraTokenParams プロパティは、トークンリクエストに API リソースを追加するために使用されます。Logto は API リソースに関して RFC 8707 に準拠しているため、両方のプロパティが必要です。

注意:

WebAssembly はクライアントサイドのアプリケーションであるため、トークンリクエストはサーバーサイドに一度だけ送信されます。この性質上、LoadUserInfo は API リソースのアクセストークンの取得と競合します。

アクセストークンを使用する

ユーザーが認証 (Authentication) されると、User?.AccessToken プロパティを使用して API リソースにアクセスできます。例えば、HttpClient を使用して API リソースにアクセスできます：

using Blorc.OpenIdConnect;

builder.Services
    .AddHttpClient("MyApiResource", client =>
    {
        client.BaseAddress = new Uri("https://my-api-resource");
    })
    .AddAccessToken(); // リクエストヘッダーにアクセス トークンを追加

さらなる読み物

エンドユーザーフロー：認証 (Authentication) フロー、アカウントフロー、組織フローコネクターを設定するあなたの API を保護する

前提条件​

インストール​

統合​

スクリプト参照を追加する​

サービスを登録する​

リダイレクト URI を設定する​

リダイレクトベースのサインインについて​

リダイレクト URI を設定する​

アプリケーションを設定する​

AuthorizeView コンポーネントを追加する​

認証 (Authentication) を設定する​

チェックポイント: アプリケーションをテストする​

ユーザー情報を取得する​

ユーザー情報を表示する​

追加のクレームをリクエストする​

ネットワークリクエストが必要なクレーム​

スコープとクレーム​

API リソース​

設定に API リソースを追加する​

アクセス トークンを使用する​

さらなる読み物​

前提条件

インストール

統合

スクリプト参照を追加する

サービスを登録する

リダイレクト URI を設定する

リダイレクトベースのサインインについて

リダイレクト URI を設定する

アプリケーションを設定する

`AuthorizeView` コンポーネントを追加する

認証 (Authentication) を設定する

チェックポイント: アプリケーションをテストする

ユーザー情報を取得する

ユーザー情報を表示する

追加のクレームをリクエストする

ネットワークリクエストが必要なクレーム

スコープとクレーム

API リソース

設定に API リソースを追加する

アクセストークンを使用する

さらなる読み物