Authentifizierung zu deiner Android (Kotlin / Java)-Anwendung hinzufügen

Diese Anleitung zeigt dir, wie du Logto in deine Android-Anwendung integrierst.

tipp

• Das Beispiel basiert auf dem View-System und dem View Model, aber die Konzepte sind die gleichen bei der Verwendung von Jetpack Compose.
• Das Beispiel ist in Kotlin geschrieben, aber die Konzepte sind die gleichen für Java.
• Sowohl Kotlin als auch Java Beispielprojekte sind in unserem SDK-Repository verfügbar.
• Das Tutorial-Video ist auf unserem YouTube-Kanal verfügbar.

Voraussetzungen

• Ein Logto Cloud-Konto oder ein selbst gehostetes Logto.
• Eine erstellte Logto-native Anwendung.
• Ein Kotlin-Android-Anwendungsprojekt.

Installation

hinweis

Die minimal unterstützte Android API-Ebene des Logto Android SDK ist Ebene 24.

Bevor du das Logto Android SDK installierst, stelle sicher, dass mavenCentral() zu deiner Repository-Konfiguration in der Gradle-Projekt-Build-Datei hinzugefügt wurde:

settings.gradle.kts

dependencyResolutionManagement {
  repositories {
    mavenCentral()
  }
}

Füge das Logto Android SDK zu deinen Abhängigkeiten hinzu:

Kotlin

build.gradle.kts

dependencies {
  implementation("io.logto.sdk:android:1.1.3")
}

Groovy

build.gradle

dependencies {
  implementation 'io.logto.sdk:android:1.1.3'
}

Da das SDK Internetzugang benötigt, musst du die folgende Berechtigung zu deiner AndroidManifest.xml-Datei hinzufügen:

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">

  <!-- Internetberechtigung hinzufügen -->
  <uses-permission android:name="android.permission.INTERNET" />

  <!-- andere Konfigurationen... -->
</manifest>

Integration

LogtoClient initialisieren

Erstelle eine LogtoViewModel.kt und initialisiere LogtoClient in diesem ViewModel:

LogtoViewModel.kt

//...mit anderen Imports
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 {
                // Hole das Application-Objekt aus extras
                val application = checkNotNull(extras[APPLICATION_KEY])
                return LogtoViewModel(application) as T
            }
        }
    }
}

erstelle dann ein LogtoViewModel für deine MainActivity.kt:

MainActivity.kt

//...mit anderen Imports
class MainActivity : AppCompatActivity() {
    private val logtoViewModel: LogtoViewModel by viewModels { LogtoViewModel.Factory }
    //...andere Codes
}

Redirect-URI konfigurieren

Bevor wir in die Details eintauchen, hier ein kurzer Überblick über die Endbenutzererfahrung. Der Anmeldeprozess kann wie folgt vereinfacht werden:

1. Deine App ruft die Anmeldemethode auf.
2. Der Benutzer wird zur Logto-Anmeldeseite umgeleitet. Bei nativen Apps wird der Systembrowser geöffnet.
3. Der Benutzer meldet sich an und wird zurück zu deiner App umgeleitet (konfiguriert als die Redirect-URI).

Bezüglich der umleitungsbasierten Anmeldung

1. Dieser Authentifizierungsprozess folgt dem OpenID Connect (OIDC) Protokoll, und Logto erzwingt strenge Sicherheitsmaßnahmen, um die Benutzeranmeldung zu schützen.
2. Wenn du mehrere Apps hast, kannst du denselben Identitätsanbieter (Logto) verwenden. Sobald sich der Benutzer bei einer App anmeldet, wird Logto den Anmeldeprozess automatisch abschließen, wenn der Benutzer auf eine andere App zugreift.

Um mehr über die Gründe und Vorteile der umleitungsbasierten Anmeldung zu erfahren, siehe Logto-Anmeldeerfahrung erklärt.

---

Wechseln wir zur Seite "Anwendungsdetails" der Logto-Konsole. Füge eine Redirect-URI io.logto.android://io.logto.sample/callback hinzu und klicke auf "Änderungen speichern".

In Android folgt die Redirect-URI dem Muster: $(LOGTO_REDIRECT_SCHEME)://$(YOUR_APP_PACKAGE)/callback:

• Das LOGTO_REDIRECT_SCHEME sollte ein benutzerdefiniertes Schema im umgekehrten Domain-Format sein.
• Das YOUR_APP_PACKAGE ist der Paketname deiner App.

Angenommen, du behandelst io.logto.android als das benutzerdefinierte LOGTO_REDIRECT_SCHEME und io.logto.sample ist dein App-Paketname, sollte die Redirect-URI io.logto.android://io.logto.sample/callback sein.

Anmeldung und Abmeldung implementieren

hinweis

Bevor du logtoClient.signIn aufrufst, stelle sicher, dass du die Redirect-URI im Admin Console korrekt konfiguriert hast.

Du kannst logtoClient.signIn verwenden, um den Benutzer anzumelden, und logtoClient.signOut, um den Benutzer abzumelden.

Zum Beispiel in einer Android-App:

LogtoModelView.kt

//...mit anderen Imports
class LogtoViewModel(application: Application) : AndroidViewModel(application) {
    // ...andere Codes

    // Füge ein Live-Datenobjekt hinzu, um den Authentifizierungsstatus zu beobachten
    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) }
            // Aktualisiere die Live-Daten
            _authenticated.postValue(logtoClient.isAuthenticated)
        }
    }

    fun signOut() {
        logtoClient.signOut { logtoException ->
            logtoException?.let { println(it) }
            // Aktualisiere die Live-Daten
            _authenticated.postValue(logtoClient.isAuthenticated)
        }
    }
}

Rufe dann die Methoden signIn und signOut in deiner Aktivität auf:

MainActivity.kt

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        //...andere Codes

        // Angenommen, du hast einen Button mit der ID "sign_in_button" in deinem Layout
        val signInButton = findViewById<Button>(R.id.sign_in_button)
        signInButton.setOnClickListener {
            logtoViewModel.signIn(this)
        }

        // Angenommen, du hast einen Button mit der ID "sign_out_button" in deinem Layout
        val signOutButton = findViewById<Button>(R.id.sign_out_button)
        signOutButton.setOnClickListener {
            if (logtoViewModel.authenticated) { // Überprüfe, ob der Benutzer authentifiziert ist
                logtoViewModel.signOut()
            }
        }

        // Beobachte den Authentifizierungsstatus, um die Benutzeroberfläche zu aktualisieren
        logtoViewModel.authenticated.observe(this) { authenticated ->
            if (authenticated) {
                // Der Benutzer ist authentifiziert
                signInButton.visibility = View.GONE
                signOutButton.visibility = View.VISIBLE
            } else {
                // Der Benutzer ist nicht authentifiziert
                signInButton.visibility = View.VISIBLE
                signOutButton.visibility = View.GONE
            }
        }

    }
}

Checkpoint: Teste deine Anwendung

Jetzt kannst du deine Anwendung testen:

1. Starte deine Anwendung, du wirst den Anmeldebutton sehen.
2. Klicke auf den Anmeldebutton, das SDK wird den Anmeldeprozess initiieren und dich zur Logto-Anmeldeseite weiterleiten.
3. Nachdem du dich angemeldet hast, wirst du zurück zu deiner Anwendung geleitet und siehst den Abmeldebutton.
4. Klicke auf den Abmeldebutton, um den lokalen Speicher zu leeren und dich abzumelden.

Benutzerinformationen abrufen

Benutzerinformationen anzeigen

Um die Informationen des Benutzers anzuzeigen, kannst du die Methode logtoClient.getIdTokenClaims() verwenden. Zum Beispiel kannst du Benutzerinformationen in einem ViewModel abrufen und dann in deiner Aktivität anzeigen:

LogtoModelView.kt

class LogtoViewModel(application: Application) : AndroidViewModel(application) {
    // ...andere Codes

    // Füge ein Live-Datenobjekt hinzu, um die ID-Token-Ansprüche zu beobachten
    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

//...mit anderen Imports
class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        //...andere Codes

        // Angenommen, du hast eine Textansicht mit der ID `user_info_text_view` in deinem Layout
        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 {
                ""
            }
        }
    }
}

Zusätzliche Ansprüche anfordern

Möglicherweise fehlen einige Benutzerinformationen im zurückgegebenen Objekt von logtoClient.getIdTokenClaims(). Dies liegt daran, dass OAuth 2.0 und OpenID Connect (OIDC) so konzipiert sind, dass sie dem Prinzip der minimalen Rechte (PoLP) folgen, und Logto auf diesen Standards basiert.

Standardmäßig werden begrenzte Ansprüche zurückgegeben. Wenn du mehr Informationen benötigst, kannst du zusätzliche Berechtigungen anfordern, um auf mehr Ansprüche zuzugreifen.

info

Ein "Anspruch (Claim)" ist eine Behauptung über ein Subjekt; eine "Berechtigung (Scope)" ist eine Gruppe von Ansprüchen. Im aktuellen Fall ist ein Anspruch ein Informationsstück über den Benutzer.

Hier ist ein nicht-normatives Beispiel für die Beziehung zwischen Berechtigung und Anspruch:

tipp

Der "sub"-Anspruch bedeutet "Subjekt", was der eindeutige Identifikator des Benutzers ist (d. h. Benutzer-ID).

Das Logto SDK wird immer drei Berechtigungen anfordern: openid, profile und offline_access.

Um zusätzliche Berechtigungen anzufordern, kannst du die Berechtigungen an das LogtoConfig-Objekt übergeben. Zum Beispiel:

LogtoViewModel.kt

private val logtoConfig = LogtoConfig(
    // ...andere Konfigurationen
    scopes = listOf("email", "phone"), // oder `listOf(UserScope.EMAIL, UserScope.PHONE)`
)

Dann kannst du auf die zusätzlichen Ansprüche im Rückgabewert von logtoClient.getIdTokenClaims() zugreifen:

logtoClient.getIdTokenClaims { logtoException, idTokenClaims ->
    println("IdTokenClaims:$idTokenClaims")
}
// Jetzt kannst du auf zusätzliche Ansprüche `claims.email`, `claims.phone` usw. zugreifen.

Ansprüche, die Netzwerk-Anfragen benötigen

Um das ID-Token nicht aufzublähen, erfordern einige Ansprüche Netzwerk-Anfragen, um abgerufen zu werden. Zum Beispiel ist der custom_data Anspruch nicht im Benutzerobjekt enthalten, selbst wenn er in den Berechtigungen angefordert wird. Um auf diese Ansprüche zuzugreifen, kannst du die logtoClient.fetchUserInfo() Methode verwenden:

LogtoViewModel.kt

logtoClient.fetchUserInfo {_, userInfoResponse ->
  println("UserInfoResponse:$userInfoResponse")
}
// Jetzt kannst du auf den Anspruch `userInfo.custom_data` zugreifen

Diese Methode wird die Benutzerinformationen abrufen, indem sie eine Anfrage an den Userinfo-Endpunkt stellt. Um mehr über die verfügbaren Berechtigungen und Ansprüche zu erfahren, siehe den Berechtigungen und Ansprüche Abschnitt.

Berechtigungen und Ansprüche

Logto verwendet OIDC Berechtigungen und Ansprüche Konventionen, um die Berechtigungen und Ansprüche für das Abrufen von Benutzerinformationen aus dem ID-Token und dem OIDC userinfo endpoint zu definieren. Sowohl "Berechtigung (Scope)" als auch "Anspruch (Claim)" sind Begriffe aus den OAuth 2.0 und OpenID Connect (OIDC) Spezifikationen.

Hier ist die Liste der unterstützten Berechtigungen (Scopes) und der entsprechenden Ansprüche (Claims):

openid

Anspruchsname	Typ	Beschreibung	Benötigt userinfo?
sub	string	Der eindeutige Identifikator des Benutzers	Nein

profile

Anspruchsname	Typ	Beschreibung	Benötigt userinfo?
name	string	Der vollständige Name des Benutzers	Nein
username	string	Der Benutzername des Benutzers	Nein
picture	string	URL des Profilbildes des Endbenutzers. Diese URL MUSS auf eine Bilddatei (zum Beispiel eine PNG-, JPEG- oder GIF-Bilddatei) verweisen und nicht auf eine Webseite, die ein Bild enthält. Beachte, dass diese URL speziell auf ein Profilfoto des Endbenutzers verweisen SOLLTE, das geeignet ist, den Endbenutzer zu beschreiben, und nicht auf ein beliebiges Foto, das vom Endbenutzer aufgenommen wurde.	Nein
created_at	number	Zeitpunkt, zu dem der Endbenutzer erstellt wurde. Die Zeit wird als Anzahl der Millisekunden seit der Unix-Epoche (1970-01-01T00:00:00Z) dargestellt.	Nein
updated_at	number	Zeitpunkt, zu dem die Informationen des Endbenutzers zuletzt aktualisiert wurden. Die Zeit wird als Anzahl der Millisekunden seit der Unix-Epoche (1970-01-01T00:00:00Z) dargestellt.	Nein

Andere Standardansprüche wie family_name, given_name, middle_name, nickname, preferred_username, profile, website, gender, birthdate, zoneinfo und locale werden ebenfalls im profile-Scope enthalten sein, ohne dass der userinfo-Endpunkt angefordert werden muss. Ein Unterschied im Vergleich zu den oben genannten Ansprüchen besteht darin, dass diese Ansprüche nur zurückgegeben werden, wenn ihre Werte nicht leer sind, während die oben genannten Ansprüche null zurückgeben, wenn die Werte leer sind.

hinweis

Im Gegensatz zu den Standardansprüchen verwenden die Ansprüche created_at und updated_at Millisekunden anstelle von Sekunden.

email

Anspruchsname	Typ	Beschreibung	Benötigt userinfo?
email	string	Die E-Mail-Adresse des Benutzers	Nein
email_verified	boolean	Ob die E-Mail-Adresse verifiziert wurde	Nein

phone

Anspruchsname	Typ	Beschreibung	Benötigt userinfo?
phone_number	string	Die Telefonnummer des Benutzers	Nein
phone_number_verified	boolean	Ob die Telefonnummer verifiziert wurde	Nein

address

Bitte siehe OpenID Connect Core 1.0 für die Details des Adressanspruchs.

custom_data

Anspruchsname	Typ	Beschreibung	Benötigt userinfo?
custom_data	object	Die benutzerdefinierten Daten des Benutzers	Ja

identities

Anspruchsname	Typ	Beschreibung	Benötigt userinfo?
identities	object	Die verknüpften Identitäten des Benutzers	Ja
sso_identities	array	Die verknüpften SSO-Identitäten des Benutzers	Ja

urn:logto:scope:organizations

Anspruchsname	Typ	Beschreibung	Benötigt userinfo?
organizations	string[]	Die Organisations-IDs, denen der Benutzer angehört	Nein
organization_data	object[]	Die Organisationsdaten, denen der Benutzer angehört	Ja

urn:logto:scope:organization_roles

Anspruchsname	Typ	Beschreibung	Benötigt userinfo?
organization_roles	string[]	Die Organisationsrollen, denen der Benutzer angehört, im Format <organization_id>:<role_name>	Nein

---

In Anbetracht der Leistung und der Datengröße bedeutet "Benötigt userinfo?" "Ja", dass der Anspruch nicht im ID-Token angezeigt wird, sondern in der Antwort des userinfo-Endpunkts zurückgegeben wird.

API-Ressourcen und Organisationen

Wir empfehlen, zuerst 🔐 Rollenbasierte Zugangskontrolle (RBAC) zu lesen, um die grundlegenden Konzepte von Logto RBAC zu verstehen und wie man API-Ressourcen richtig einrichtet.

Logto-Client konfigurieren

Sobald du die API-Ressourcen eingerichtet hast, kannst du sie bei der Konfiguration von Logto in deiner App hinzufügen:

LogtoViewModel.kt

val logtoConfig = LogtoConfig(
    //...other configs
    resources = listOf("https://shopping.your-app.com/api", "https://store.your-app.com/api"), // API-Ressourcen hinzufügen
)

Jede API-Ressource hat ihre eigenen Berechtigungen (Berechtigungen).

Zum Beispiel hat die Ressource https://shopping.your-app.com/api die Berechtigungen shopping:read und shopping:write, und die Ressource https://store.your-app.com/api hat die Berechtigungen store:read und store:write.

Um diese Berechtigungen anzufordern, kannst du sie bei der Konfiguration von Logto in deiner App hinzufügen:

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"),
)

Du wirst bemerken, dass Berechtigungen separat von API-Ressourcen definiert sind. Dies liegt daran, dass Resource Indicators for OAuth 2.0 spezifiziert, dass die endgültigen Berechtigungen für die Anfrage das kartesische Produkt aller Berechtigungen bei allen Zielservices sein werden.

Somit können im obigen Fall die Berechtigungen aus der Definition in Logto vereinfacht werden, beide API-Ressourcen können read und write Berechtigungen ohne Präfix haben. Dann, in der Logto-Konfiguration:

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"),
)

Für jede API-Ressource wird sowohl read als auch write Berechtigungen angefordert.

hinweis

Es ist in Ordnung, Berechtigungen anzufordern, die in den API-Ressourcen nicht definiert sind. Zum Beispiel kannst du die Berechtigung email anfordern, auch wenn die API-Ressourcen die Berechtigung email nicht verfügbar haben. Nicht verfügbare Berechtigungen werden sicher ignoriert.

Nach der erfolgreichen Anmeldung wird Logto die entsprechenden Berechtigungen an API-Ressourcen gemäß den Rollen des Benutzers ausstellen.

Zugangstoken für die API-Ressource abrufen

Um das Zugangstoken für eine spezifische API-Ressource abzurufen, kannst du die Methode getAccessToken verwenden:

LogtoViewModel.kt

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

Diese Methode gibt ein JWT-Zugangstoken zurück, das verwendet werden kann, um auf die API-Ressource zuzugreifen, wenn der Benutzer die entsprechenden Berechtigungen hat. Wenn das aktuell zwischengespeicherte Zugangstoken abgelaufen ist, versucht diese Methode automatisch, ein Auffrischungstoken zu verwenden, um ein neues Zugangstoken zu erhalten.

Organisationstokens abrufen

Wenn Organisationen neu für dich sind, lies bitte 🏢 Organisationen (Multi-Tenancy), um loszulegen.

Du musst die Berechtigung UserScope.Organizations hinzufügen, wenn du den Logto-Client konfigurierst:

LogtoViewModel.kt

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

Sobald der Benutzer angemeldet ist, kannst du das Organisationstoken für den Benutzer abrufen:

LogtoViewModel.kt

// Ersetze den Parameter durch eine gültige Organisations-ID.
// Gültige Organisations-IDs für den Benutzer können im ID-Token-Anspruch `organizations` gefunden werden.
logtoClient.getOrganizationToken("organization-id") { logtoException, organizationToken ->
    logtoException?.let { println(it) }
    organizationToken?.let { println(it) }
}

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

Organisations-API-Ressourcen

Um ein Zugangstoken für eine API-Ressource in einer Organisation abzurufen, kannst du die Methode getAccessToken mit sowohl der API-Ressource als auch der Organisations-ID als Parameter verwenden:

LogtoViewModel.kt

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

Weiterführende Lektüre

Endbenutzerflüsse: Authentifizierungsflüsse, Kontoflüsse und Organisationsflüsse Connectors konfigurieren Schütze deine API