Android (Kotlin / Java) アプリケーションへ認証機能の追加

このガイドでは、Android アプリケーションに Logto を統合する方法を紹介します。

ヒント:

この例は View システムと View Model に基づいていますが、Jetpack Compose を使用する場合でも概念は同じです。
この例は Kotlin で書かれていますが、Java でも概念は同じです。
Kotlin と Java のサンプルプロジェクトは、私たちの SDK リポジトリで利用可能です。
チュートリアルビデオは、私たちの YouTube チャンネルで視聴できます。

前提条件

Logto Cloud アカウント、またはセルフホスト Logto。
作成済みの Logto ネイティブアプリケーション。
Kotlin Android アプリケーションプロジェクト。

インストール

注記:

Logto Android SDK のサポートされている最小 Android API レベルは 24 です。

Logto Android SDK には 2 つの主要バージョンがあります：

v3：サインイン体験を Chrome Custom Tabs（システムブラウザ）で開きます。これによりパスキーサインインが可能となり、ブラウザセッションが共有されます。なお、v3 では WeChat (Native) および Alipay (Native) コネクターのサポートが削除されています。代わりに WeChat (Web) および Alipay (Web) を利用できます（これらはブラウザ経由で動作します）。ネイティブコネクターに依存している場合は v2 をご利用ください。
v2：サインイン体験を埋め込み WebView で開きます。これはネイティブソーシャルコネクターに必要ですが、パスキーサインインはサポートされません（WebView はパスキーの基盤となる WebAuthn をサポートしていません）。

このガイドでは両バージョンをカバーしています。下記のタブでバージョンを選択すると、ガイド全体でその選択が同期されます。

Logto Android SDK をインストールする前に、Gradle プロジェクトのビルドファイルで mavenCentral() がリポジトリ設定に追加されていることを確認してください：

settings.gradle.kts
dependencyResolutionManagement {
  repositories {
    mavenCentral()
  }
}

依存関係に Logto Android SDK を追加します：

最新版の v3 リリースをバージョンとして使用します：

Kotlin
Groovy

build.gradle.kts
dependencies {
  implementation("io.logto.sdk:android:3.0.0")
}

build.gradle
dependencies {
  implementation 'io.logto.sdk:android:3.0.0'
}

Kotlin
Groovy

build.gradle.kts
dependencies {
  implementation("io.logto.sdk:android:2.0.3")
}

build.gradle
dependencies {
  implementation 'io.logto.sdk:android:2.0.3'
}

SDK はインターネットアクセスが必要なため、AndroidManifest.xml ファイルに次のパーミッションを追加してください：

AndroidManifest.xml
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
  xmlns:tools="http://schemas.android.com/tools">

  <!-- インターネットパーミッションを追加 -->
  <uses-permission android:name="android.permission.INTERNET" />

  <!-- その他の設定... -->
</manifest>

統合

LogtoClient の初期化

LogtoViewModel.kt を作成し、このビューモデルで LogtoClient を初期化します：

LogtoViewModel.kt
//...他のインポート
import io.logto.sdk.android.LogtoClient
import io.logto.sdk.android.type.LogtoConfig

class LogtoViewModel(application: Application) : AndroidViewModel(application) {
    private val logtoConfig = LogtoConfig(
          endpoint = "<your-logto-endpoint>",
          appId = "<your-app-id>",
          scopes = null,
          resources = null,
          usingPersistStorage = true,
    )

    private val logtoClient = LogtoClient(logtoConfig, application)

    companion object {
        val Factory: ViewModelProvider.Factory = object : ViewModelProvider.Factory {
            @Suppress("UNCHECKED_CAST")
            override fun <T : ViewModel> create(
                modelClass: Class<T>,
                extras: CreationExtras
            ): T {
                // extras から Application オブジェクトを取得
                val application = checkNotNull(extras[APPLICATION_KEY])
                return LogtoViewModel(application) as T
            }
        }
    }
}

次に、MainActivity.kt のために LogtoViewModel を作成します：

MainActivity.kt
//...他のインポート
class MainActivity : AppCompatActivity() {
    private val logtoViewModel: LogtoViewModel by viewModels { LogtoViewModel.Factory }
    //...他のコード
}

リダイレクト URI の設定

詳細に入る前に、エンドユーザー体験の概要を簡単にご紹介します。サインインプロセスは次のようにシンプルにまとめられます：

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

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

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

Logto コンソールのアプリケーション詳細ページに切り替えましょう。リダイレクト URI io.logto.android://io.logto.sample/callback を追加し、「変更を保存」をクリックします。

Android では、リダイレクト URI は $(LOGTO_REDIRECT_SCHEME)://$(YOUR_APP_PACKAGE)/callback というパターンに従います：

LOGTO_REDIRECT_SCHEME はリバースドメイン形式のカスタムスキームにしてください。
YOUR_APP_PACKAGE はアプリのパッケージ名です。

たとえば、io.logto.android をカスタム LOGTO_REDIRECT_SCHEME とし、io.logto.sample をアプリのパッケージ名とする場合、リダイレクト URI は io.logto.android://io.logto.sample/callback となります。

v3 では、サインイン体験は Custom Tab（システムブラウザ）で開かれ、リダイレクトは OS レベルのインテントフィルターを通じてアプリに戻されます。リダイレクト URI のスキームをアプリのビルドファイルで logtoRedirectScheme マニフェストプレースホルダーとして宣言する必要があります：

Kotlin
Groovy

build.gradle.kts
android {
  defaultConfig {
    manifestPlaceholders["logtoRedirectScheme"] = "io.logto.android"
  }
}

build.gradle
android {
  defaultConfig {
    manifestPlaceholders.logtoRedirectScheme = 'io.logto.android'
  }
}

さらに、v3 では Android のインテントフィルターマッチングによってリダイレクト URI パターンが強制されるため、パターンから外れたリダイレクト URI はアプリに届きません：

スキームは logtoRedirectScheme マニフェストプレースホルダーと一致する必要があります。
ホストは applicationId でなければなりません。
パスは /callback でなければなりません。

スキームとホストは小文字で統一してください。インテントフィルターマッチングは大文字小文字を区別し、ブラウザはスキームを小文字に変換します。

カスタムスキームの代わりに App Links を使うには？

カスタムスキームの代わりに Android App Links（所有ドメイン上の https リダイレクト URI）を使うには：

Digital Asset Links ファイルを https://your.domain/.well-known/assetlinks.json にホストし、アプリケーション ID と署名証明書の SHA-256 フィンガープリントを宣言します。Play App Signing で公開する場合、リリースフィンガープリントは Play Console の セットアップ > アプリ署名 で確認できます。ファイルは Content-Type: application/json で HTTP 200、リダイレクトなしで配信してください。

SDK のリダイレクト受信アクティビティ io.logto.sdk.android.auth.logto.LogtoRedirectReceiverActivity に App Links インテントフィルターを AndroidManifest.xml に宣言します。カスタムスキームを全く使わない場合は、SDK の組み込みフィルターを tools:node="removeAll" で削除し、logtoRedirectScheme マニフェストプレースホルダーは不要です：

AndroidManifest.xml
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
  xmlns:tools="http://schemas.android.com/tools">
  <application>
    <activity android:name="io.logto.sdk.android.auth.logto.LogtoRedirectReceiverActivity">
      <!-- カスタムスキームリダイレクトも併用する場合はこの行を省略してください。 -->
      <intent-filter tools:node="removeAll" />
      <intent-filter android:autoVerify="true">
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data android:scheme="https" android:host="your.domain" android:path="/callback" />
      </intent-filter>
    </activity>
  </application>
</manifest>

Logto コンソールのアプリケーション詳細ページで https://your.domain/callback をリダイレクト URI（サインアウトにも使う場合はポストサインアウトリダイレクト URI）として追加し、signIn / signOut に渡します。

コールバックは実際にドメイン上の URL となるため、App Links をサーバーリダイレクトで起動しないブラウザ向けにフォールバックページ（例：「アプリに戻る」ボタン）を用意してください。ボタンは現在の URL へのリンク（例：href を window.location.href に設定）だけで十分です。認可パラメーターはクエリ文字列に含まれており、ユーザー操作によるクリックで同じ URL が再度アプリにルーティングされるチャンスが生まれます。Android 12 以降では未検証ドメインはアプリを開かないため、assetlinks.json の不備はサイレントに失敗します。検証状態は adb shell pm get-app-links <applicationId> で確認できます。

注記:

logtoClient.signIn を呼び出す前に、Admin Console でリダイレクト URI が正しく設定されていることを確認してください。 :::

logtoClient.signIn を使ってユーザーのサインイン、logtoClient.signOut を使ってユーザーのサインアウトができます。

v3 では、logtoClient.signOut は完全なサインアウトを実行します：ローカルの認証情報をクリアし、リフレッシュトークン (Refresh token) を取り消し、エンドセッションエンドポイントをブラウザで開いて Logto セッションを終了します。その後、ブラウザはポストサインアウトリダイレクト URI を通じてアプリに戻ります。使用前に Logto コンソールのアプリケーション詳細ページに移動し、ポストサインアウトリダイレクト URI io.logto.android://io.logto.sample/callback を追加して「変更を保存」をクリックしてください。ポストサインアウトリダイレクト URI はリダイレクト URI と同じパターンに従い、そのスキームも logtoRedirectScheme マニフェストプレースホルダーと一致する必要があります。

例えば、Android アプリの場合：

LogtoModelView.kt
//...他のインポート
class LogtoViewModel(application: Application) : AndroidViewModel(application) {
    // ...他のコード

    // 認証 (Authentication) 状態を監視する LiveData を追加
    private val _authenticated = MutableLiveData(logtoClient.isAuthenticated)
    val authenticated: LiveData<Boolean>
        get() = _authenticated

    fun signIn(context: Activity) {
        logtoClient.signIn(context, "io.logto.android://io.logto.sample/callback") { logtoException ->
            logtoException?.let { println(it) }
            // LiveData を更新
            _authenticated.postValue(logtoClient.isAuthenticated)
        }
    }

    fun signOut(context: Activity) {
        logtoClient.signOut(context, "io.logto.android://io.logto.sample/callback") { logtoException ->
            logtoException?.let { println(it) }
            // LiveData を更新
            _authenticated.postValue(logtoClient.isAuthenticated)
        }
    }
}

次に、アクティビティ内で signIn と signOut メソッドを呼び出します：

MainActivity.kt
class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        //...他のコード

        // レイアウトに id "sign_in_button" のボタンがあると仮定
        val signInButton = findViewById<Button>(R.id.sign_in_button)
        signInButton.setOnClickListener {
            logtoViewModel.signIn(this)
        }

        // レイアウトに id "sign_out_button" のボタンがあると仮定
        val signOutButton = findViewById<Button>(R.id.sign_out_button)
        signOutButton.setOnClickListener {
            if (logtoViewModel.authenticated) { // ユーザーが認証 (Authentication) されているか確認
                logtoViewModel.signOut(this)
            }
        }

        // 認証 (Authentication) 状態を監視して UI を更新
        logtoViewModel.authenticated.observe(this) { authenticated ->
            if (authenticated) {
                // ユーザーが認証 (Authentication) されている
                signInButton.visibility = View.GONE
                signOutButton.visibility = View.VISIBLE
            } else {
                // ユーザーが認証 (Authentication) されていない
                signInButton.visibility = View.VISIBLE
                signOutButton.visibility = View.GONE
            }
        }

    }
}

注記:

ポストサインアウトリダイレクト URI なしで logtoClient.signOut(context) を呼び出すこともできます。この場合、コンソールでの設定は不要です：ブラウザに Logto のサインアウトページが表示され、ユーザーは手動で閉じてアプリに戻ります。
UI コンテキストが利用できない場合は、logtoClient.clearCredentials を呼び出してローカルの認証情報をクリアし、リフレッシュトークン (Refresh token) を取り消すことができます。ただし、この場合ブラウザ上の Logto セッションは維持されるため、次回の signIn でそのセッションを通じてユーザーがサイレントにサインインされる可能性があります。

例えば、Android アプリの場合：

LogtoModelView.kt
//...他のインポート
class LogtoViewModel(application: Application) : AndroidViewModel(application) {
    // ...他のコード

    // 認証 (Authentication) 状態を監視する LiveData を追加
    private val _authenticated = MutableLiveData(logtoClient.isAuthenticated)
    val authenticated: LiveData<Boolean>
        get() = _authenticated

    fun signIn(context: Activity) {
        logtoClient.signIn(context, "io.logto.android://io.logto.sample/callback") { logtoException ->
            logtoException?.let { println(it) }
            // LiveData を更新
            _authenticated.postValue(logtoClient.isAuthenticated)
        }
    }

    fun signOut() {
        logtoClient.signOut { logtoException ->
            logtoException?.let { println(it) }
            // LiveData を更新
            _authenticated.postValue(logtoClient.isAuthenticated)
        }
    }
}

次に、アクティビティ内で signIn と signOut メソッドを呼び出します：

MainActivity.kt
class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        //...他のコード

        // レイアウトに id "sign_in_button" のボタンがあると仮定
        val signInButton = findViewById<Button>(R.id.sign_in_button)
        signInButton.setOnClickListener {
            logtoViewModel.signIn(this)
        }

        // レイアウトに id "sign_out_button" のボタンがあると仮定
        val signOutButton = findViewById<Button>(R.id.sign_out_button)
        signOutButton.setOnClickListener {
            if (logtoViewModel.authenticated) { // ユーザーが認証 (Authentication) されているか確認
                logtoViewModel.signOut()
            }
        }

        // 認証 (Authentication) 状態を監視して UI を更新
        logtoViewModel.authenticated.observe(this) { authenticated ->
            if (authenticated) {
                // ユーザーが認証 (Authentication) されている
                signInButton.visibility = View.GONE
                signOutButton.visibility = View.VISIBLE
            } else {
                // ユーザーが認証 (Authentication) されていない
                signInButton.visibility = View.VISIBLE
                signOutButton.visibility = View.GONE
            }
        }

    }
}

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

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

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

ユーザー情報の取得

ユーザー情報の表示

ユーザー情報を表示するには、logtoClient.getIdTokenClaims() メソッドを利用できます。たとえば、ViewModel でユーザー情報を取得し、アクティビティで表示できます：

LogtoModelView.kt
class LogtoViewModel(application: Application) : AndroidViewModel(application) {
    // ...他のコード

    // id token claims を監視する LiveData を追加
    private val _idTokenClaims = MutableLiveData<IdTokenClaims>()
    val idTokenClaims: LiveData<IdTokenClaims>
        get() = _idTokenClaims

    fun getIdTokenClaims() {
        logtoClient.getIdTokenClaims { logtoException, idTokenClaims ->
            logtoException?.let { _logtoException.postValue(it) } ?: _idTokenClaims.postValue(idTokenClaims)
        }
    }
}

MainActivity.kt
//...他の import
class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        //...他のコード

        // レイアウトに id `user_info_text_view` の TextView があると仮定
        val userInfoResponseTextView: TextView = findViewById(R.id.user_info_text_view)
        logtoViewModel.userInfoResponse.observe(this) { userInfoResponse ->
            userInfoResponseTextView.text = if (userInfoResponse !== null) {
                val json = Gson().toJson(userInfoResponse, UserInfoResponse::class.java)
                JSONObject(json).toString(2)
            } else {
                ""
            }
        }
    }
}

追加クレームのリクエスト

logtoClient.getIdTokenClaims() から返されるオブジェクトに一部のユーザー情報が欠けていることがあります。これは、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。

追加のスコープをリクエストするには、LogtoConfig オブジェクトにスコープを渡します。例：

LogtoViewModel.kt
private val logtoConfig = LogtoConfig(
    // ...他の設定
    scopes = listOf("email", "phone"), // または `listOf(UserScope.EMAIL, UserScope.PHONE)`
)

その後、logtoClient.getIdTokenClaims() の戻り値で追加クレームにアクセスできます：

logtoClient.getIdTokenClaims { logtoException, idTokenClaims ->
    println("IdTokenClaims:$idTokenClaims")
}
// 追加クレーム `claims.email`、`claims.phone` などにアクセスできます

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

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

LogtoViewModel.kt
logtoClient.fetchUserInfo {_, userInfoResponse ->
  println("UserInfoResponse:$userInfoResponse")
}
// これで claim `userInfo.custom_data` にアクセスできます

このメソッドは、userinfo エンドポイントにリクエストを送信してユーザー情報を取得します。利用可能なスコープとクレームについて詳しくは、スコープとクレームのセクションを参照してください。

スコープとクレーム

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

標準の OIDC クレーム (Claim) については、ID トークンへの含有はリクエストされたスコープ (Scope) によって厳密に決定されます。拡張クレーム (Claim)（例：custom_data や organizations）は、カスタム ID トークン設定を通じて ID トークンに追加で表示するように構成できます。

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

標準 OIDC スコープ

openid（デフォルト）

Claim name	Type	説明
sub	`string`	ユーザーの一意の識別子

profile（デフォルト）

Claim name	Type	説明
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）からのミリ秒数で表されます。

その他の標準クレーム (Standard Claims) には、family_name、given_name、middle_name、nickname、preferred_username、profile、website、gender、birthdate、zoneinfo、locale などがあり、これらも profile スコープに含まれます（userinfo エンドポイントをリクエストする必要はありません）。上記のクレームとの違いは、これらのクレームは値が空でない場合のみ返される点です。一方、上記のクレームは値が空の場合 null が返されます。

注記:

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

email

Claim name	Type	説明
email	`string`	ユーザーのメールアドレス
email_verified	`boolean`	メールアドレスが認証済みかどうか

phone

Claim name	Type	説明
phone_number	`string`	ユーザーの電話番号
phone_number_verified	`boolean`	電話番号が認証済みかどうか

address

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

備考:

（デフォルト） と記載されたスコープは常に Logto SDK によってリクエストされます。標準 OIDC スコープ下のクレーム (Claims) は、対応するスコープがリクエストされた場合、常に ID トークン (ID token) に含まれます — 無効化できません。

拡張スコープ

以下のスコープは Logto によって拡張されており、userinfo エンドポイントを通じてクレーム (Claims) を返します。これらのクレームは Console > Custom JWT を通じて ID トークン (ID token) に直接含めるよう設定することもできます。詳細はカスタム ID トークンを参照してください。

custom_data

Claim name	Type	説明	デフォルトで ID トークンに含まれるか
custom_data	`object`	ユーザーのカスタムデータ

identities

Claim name	Type	説明	デフォルトで ID トークンに含まれるか
identities	`object`	ユーザーのリンク済みアイデンティティ
sso_identities	`array`	ユーザーのリンク済み SSO アイデンティティ

roles

Claim name	Type	説明	デフォルトで ID トークンに含まれるか
roles	`string[]`	ユーザーのロール	✅

urn:logto:scope:organizations

Claim name	Type	説明	デフォルトで ID トークンに含まれるか
organizations	`string[]`	ユーザーが所属する組織 ID	✅
organization_data	`object[]`	ユーザーが所属する組織データ

注記:

これらの組織クレーム (Organization Claims) は、不透明トークン (Opaque token) を使用している場合でも userinfo エンドポイント経由で取得できます。ただし、不透明トークン (Opaque token) は組織トークン (Organization token) として組織固有リソースへのアクセスには使用できません。詳細は不透明トークン (Opaque token) と組織 (Organizations) を参照してください。

urn:logto:scope:organization_roles

Claim name	Type	説明	デフォルトで ID トークンに含まれるか
organization_roles	`string[]`	ユーザーが所属する組織ロール（`<organization_id>:<role_name>` 形式）	✅

API リソースと組織

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

Logto クライアントの設定

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

LogtoViewModel.kt
val logtoConfig = LogtoConfig(
    //...other configs
    resources = listOf("https://shopping.your-app.com/api", "https://store.your-app.com/api"), // API リソースを追加
)

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

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

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

LogtoViewModel.kt
val logtoConfig = LogtoConfig(
    // ..other configs
    scopes = listOf("shopping:read", "shopping:write", "store:read", "store:write"),
    resources = listOf("https://shopping.your-app.com/api", "https://store.your-app.com/api"),
)

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

したがって、上記のケースでは、Logto での定義からスコープを簡略化できます。両方の API リソースは、プレフィックスなしで read と write スコープを持つことができます。その後、Logto の設定では：

LogtoViewModel.kt
val logtoConfig = LogtoConfig(
    // ...other configs
    scopes = listOf("read", "write"),
    resources = listOf("https://shopping.your-app.com/api", "https://store.your-app.com/api"),
)

各 API リソースは、read と write の両方のスコープを要求します。

注記:

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

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

API リソース用のアクセストークンの取得

特定の API リソースのアクセストークンを取得するには、getAccessToken メソッドを使用できます：

LogtoViewModel.kt
logtoClient.getAccessToken("https://shopping.your-app.com/api") { logtoException, accessToken ->
    logtoException?.let { println(it) }
    accessToken?.let { println(it) }
}

このメソッドは、ユーザーが関連する権限を持っている場合に API リソースにアクセスするために使用できる JWT アクセストークンを返します。現在キャッシュされているアクセストークンが期限切れの場合、このメソッドは自動的にリフレッシュトークンを使用して新しいアクセストークンを取得しようとします。

組織トークンの取得

組織 (Organization) が初めての場合は、🏢 組織 (マルチテナンシー) を読んで始めてください。

Logto クライアントを設定する際に、UserScope.Organizations スコープを追加する必要があります：

LogtoViewModel.kt
val logtoConfig = LogtoConfig(
    // ...other configs
    scopes = listOf(UserScope.Organizations),
)

ユーザーがサインインしたら、ユーザーのための組織トークンを取得できます：

LogtoViewModel.kt
// パラメーターを有効な組織 ID に置き換えます。
// ユーザーに対する有効な組織 ID は、ID トークンのクレーム `organizations` にあります。
logtoClient.getOrganizationToken("organization-id") { logtoException, organizationToken ->
    logtoException?.let { println(it) }
    organizationToken?.let { println(it) }
}

// または
logtoClient.getOrganizationTokenClaims("organization-id") { logtoException, claims ->
    logtoException?.let { println(it) }
    claims?.let { println(it) }
}

組織 API リソース

組織内の API リソースのアクセストークンを取得するには、getAccessToken メソッドを使用し、API リソースと組織 ID の両方をパラメーターとして渡すことができます：

LogtoViewModel.kt
logtoClient.getAccessToken(
  'https://shopping.your-app.com/api',
  organizationId
) { logtoException, accessToken ->
    println("AccessToken:$accessToken")
}

さらに読む

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

前提条件​

インストール​

統合​

LogtoClient の初期化​

リダイレクト URI の設定​

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

カスタムスキームの代わりに App Links を使うには？​

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

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

ユーザー情報の取得​

ユーザー情報の表示​

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

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

スコープとクレーム​

標準 OIDC スコープ​

拡張スコープ​

API リソースと組織​

Logto クライアントの設定​

API リソース用のアクセス トークンの取得​

組織トークンの取得​

組織 API リソース​

さらに読む​