Angular アプリケーションへ認証機能の追加

ヒント:

以下のデモは Angular 18.0.0 と angular-auth-oidc-client に基づいて構築されています。
サンプルプロジェクトは GitHub リポジトリで利用可能です。

前提条件

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

インストール

Logto JS コア SDK と Angular OIDC クライアントライブラリをインストールします：

npm
pnpm
yarn

npm i @logto/js angular-auth-oidc-client

pnpm add @logto/js angular-auth-oidc-client

yarn add @logto/js angular-auth-oidc-client

統合

アプリケーションの設定

Angular プロジェクトで、app.config.ts に認証プロバイダーを追加します：

app/app.config.ts
import { buildAngularAuthConfig } from '@logto/js';
import { provideAuth } from 'angular-auth-oidc-client';

export const appConfig: ApplicationConfig = {
  providers: [
    provideHttpClient(withFetch()),
    provideAuth({
      config: buildAngularAuthConfig({
        endpoint: '<your-logto-endpoint>',
        appId: '<your-app-id>',
        redirectUri: 'http://localhost:3000/callback',
        postLogoutRedirectUri: 'http://localhost:3000/',
      }),
    }),
    // ...他のプロバイダー
  ],
};

リダイレクト 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 セクションとして追加します。

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

リダイレクトの処理

http://localhost:3000/callback をリダイレクト URI として使用するため、適切に処理する必要があります。angular-auth-oidc-client ライブラリはリダイレクトの処理をサポートしています。認証プロバイダーの設定を適切に行うだけで、ライブラリが残りを処理します。

app/app.config.ts
export const appConfig: ApplicationConfig = {
  providers: [
    provideAuth({
      config: buildAngularAuthConfig({
        // ...他の設定
        redirectUri: 'http://localhost:3000/callback',
        postLogoutRedirectUri: 'http://localhost:3000/',
      }),
    }),
    // ...他のプロバイダー
  ],
};

サインインとサインアウトを実装したいコンポーネント（例えば、app.component.ts）で、OidcSecurityService をインジェクトし、それを使用してサインインとサインアウトを行います。

app/app.component.ts
import { OidcSecurityService } from 'angular-auth-oidc-client';

export class AppComponent implements OnInit {
  constructor(public oidcSecurityService: OidcSecurityService) {}

  signIn() {
    this.oidcSecurityService.authorize();
  }

  signOut() {
    this.oidcSecurityService.logoff().subscribe((result) => {
      console.log('app sign-out', result);
    });
  }
}

次に、テンプレートにサインインとサインアウトのボタンを追加します：

app/app.component.html
<button (click)="signIn()">Sign in</button>
<br />
<button (click)="signOut()">Sign out</button>

.signOut() を呼び出すと、存在する場合、メモリと localStorage 内のすべての Logto データがクリアされます。

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

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

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

ユーザー情報の取得

ユーザーが正常にサインインすると、Logto はユーザー情報クレームを含む ID トークンを発行します。ID トークンは JSON Web Token (JWT) です。

ユーザー情報クレームは、サインイン時にユーザーが使用したスコープに依存して取得できることに注意が必要です。パフォーマンスとデータサイズを考慮して、ID トークンにはすべてのユーザークレームが含まれていない場合があります。一部のユーザークレームは userinfo エンドポイントでのみ利用可能です（以下の関連リストを参照）。

buildAngularAuthConfig() ユーティリティは、設定に resource が提供されていない場合、autoUserInfo と renewUserInfoAfterTokenRenew を有効にします。これは、ユーザーがサインインした後に Logto が自動的にユーザー情報を取得し、トークンが更新された後にユーザー情報を更新することを意味します。

備考:

angular-auth-oidc-client ライブラリの設定について詳しく知るには、公式ドキュメントを参照してください。

ユーザー情報の表示

OidcSecurityService は、認証状態およびユーザー情報を購読するための便利な方法を提供します：

app/app.component.ts
import { OidcSecurityService } from 'angular-auth-oidc-client';
import { decodeIdToken, type IdTokenClaims } from '@logto/js';

export class AppComponent implements OnInit {
  isAuthenticated = false;
  idTokenClaims?: IdTokenClaims;
  accessToken?: string;

  constructor(public oidcSecurityService: OidcSecurityService) {}

  ngOnInit() {
    this.oidcSecurityService.checkAuth().subscribe(({ isAuthenticated, idToken, accessToken }) => {
      console.log('app authenticated', isAuthenticated, idToken);
      this.isAuthenticated = isAuthenticated;
      this.idTokenClaims = decodeIdToken(idToken);
      this.accessToken = accessToken;
    });
  }

  // ...other methods
}

テンプレートで使用します：

app/app.component.html
<button *ngIf="!isAuthenticated" (click)="signIn()">Sign in</button>
<ng-container *ngIf="isAuthenticated">
  <pre>{{ idTokenClaims | json }}</pre>
  <p>Access token: {{ accessToken }}</p>
  <!-- ... -->
  <button (click)="signOut()">Sign out</button>
</ng-container>

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

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

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

備考:

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

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

ヒント:

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

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

追加のスコープをリクエストするには、認証プロバイダーの設定を構成します：

app/app.config.ts
import { UserScope, buildAngularAuthConfig } from '@logto/js';

export const appConfig: ApplicationConfig = {
  providers: [
    provideHttpClient(withFetch()),
    provideAuth({
      config: buildAngularAuthConfig({
        // ...other configs
        scopes: [
          UserScope.Email,
          UserScope.Phone,
          UserScope.CustomData,
          UserScope.Identities,
          UserScope.Organizations,
        ],
      }),
    }),
    // ...other providers
  ],
};

その後、idToken の戻り値で追加のクレームにアクセスできます。

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

ID トークンの肥大化を防ぐために、一部のクレーム (Claims) は取得するためにネットワークリクエストが必要です。例えば、custom_data クレームはスコープで要求されてもユーザーオブジェクトに含まれません。これらのクレームにアクセスするには、 userData オプションを設定できます：

app/app.component.ts
import { OidcSecurityService } from 'angular-auth-oidc-client';
import { type UserInfoResponse } from '@logto/js';

export class AppComponent implements OnInit {
isAuthenticated = false;
userData?: UserInfoResponse;
accessToken?: string;

constructor(public oidcSecurityService: OidcSecurityService) {}

ngOnInit() {
  this.oidcSecurityService
    .checkAuth()
    .subscribe(({ isAuthenticated, userData, accessToken }) => {
      console.log('app authenticated', isAuthenticated, idToken);
      this.isAuthenticated = isAuthenticated;
      this.userData = userData;
      this.accessToken = accessToken;
    });
}

// ...other methods
}

// Now you can access the claim `userData.custom_data`

userData を設定することで、SDK はユーザーがサインインした後に userinfo エンドポイントにリクエストを送信してユーザー情報を取得し、リクエストが完了すると userData が利用可能になります。

スコープとクレーム

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

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

openid

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

profile

クレーム名	タイプ	説明	ユーザー情報が必要か？
name	`string`	ユーザーのフルネーム	いいえ
username	`string`	ユーザーのユーザー名	いいえ
picture	`string`	エンドユーザーのプロフィール画像の URL。この URL は画像ファイル（例：PNG、JPEG、または GIF 画像ファイル）を参照する必要があります。画像を含む Web ページを参照してはいけません。この 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 アイデンティティ	はい

roles

クレーム名	タイプ	説明	ユーザー情報が必要か？
roles	`string[]`	ユーザーのロール	いいえ

urn:logto:scope:organizations

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

urn:logto:scope:organization_roles

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

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

API リソース

API リソース用に `angular-auth-oidc-client` を設定する

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

API リソースを設定したら、アプリで Logto を設定する際にそれらを追加できます：

/app/app.config.ts
export const appConfig: ApplicationConfig = {
  providers: [
    provideHttpClient(withFetch()),
    provideAuth({
      config: buildAngularAuthConfig({
        // ...other config
        resource: 'https://your-api-resource.com',
      }),
    }),
    // ...other providers
  ],
};

各 API リソースには独自の権限 (スコープ) があります。

例えば、https://shopping.your-app.com/api リソースには shopping:read と shopping:write の権限があり、https://store.your-app.com/api リソースには store:read と store:write の権限があります。

これらの権限を要求するには、アプリで Logto を設定する際にそれらを追加できます：

app/app.config.ts
export const appConfig: ApplicationConfig = {
  providers: [
    provideHttpClient(withFetch()),
    provideAuth({
      config: buildAngularAuthConfig({
        // ...other config
        resource: 'https://your-api-resource.com',
        scopes: ['openid', 'profile', 'offline_access', 'read', 'write'],
      }),
    }),
    // ...other providers
  ],
};

スコープが API リソースとは別に定義されていることに気付くかもしれません。これは、OAuth 2.0 のリソースインジケーターが、リクエストの最終的なスコープはすべてのターゲットサービスでのすべてのスコープの直積になると指定しているためです。

注記:

API リソースで定義されていないスコープを要求しても問題ありません。例えば、API リソースに email スコープが利用できなくても、email スコープを要求できます。利用できないスコープは安全に無視されます。

サインインが成功すると、Logto はユーザーのロールに応じて適切なスコープを API リソースに発行します。

これで、アクセストークンはランダムな文字列（不透明トークン）ではなく、JSON Web Token (JWT) 形式になります。

警告:

resource が設定されると、autoUserInfo と renewUserInfoAfterTokenRenew の両方が無効になります。これは、アクセストークンがユーザー情報エンドポイントではなく、特定の API リソースのために要求されるためです。

現在、Logto の公式 SDK のみがユーザー情報と API リソースアクセストークンの両方を要求する機能をサポートしています。両方を要求する必要がある場合は、お気軽にお問い合わせください。

さらなる読み物

エンドユーザーフロー：認証 (Authentication) フロー、アカウントフロー、組織フローコネクターの設定認可 (Authorization)

前提条件​

インストール​

統合​

アプリケーションの設定​

リダイレクト URI の設定​

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

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

リダイレクトの処理​

サインインとサインアウトの実装​

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

ユーザー情報の取得​

ユーザー情報の表示​

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

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

スコープとクレーム​

API リソース​

API リソース用に angular-auth-oidc-client を設定する​

さらなる読み物​