Name Description Size # Account Management URLs Signed-in applications should not attempt to perform an account-level management (such as changing profile data or managing devices) using native UI. Instead, they should offer the user the opportunity to visit their account management pages on the web. The methods in this section provide URLs at which the user can perform various account-management activities. 3193 # Signing in and out These are methods for managing the signed-in state, such as authenticating via an OAuth flow or disconnecting from the user's account. The Firefox Accounts system supports two methods for connecting an application to a user's account: - A traditional OAuth flow, where the user is directed to a webpage to enter their account credentials and then redirected back to the application. This is exposed by the [`begin_oauth_flow`](FirefoxAccount::begin_oauth_flow) method. - A device pairing flow, where the user scans a QRCode presented by another app that is already connected to the account, which then directs them to a webpage for a simplified signing flow. This is exposed by the [`begin_pairing_flow`](FirefoxAccount::begin_pairing_flow) method. Technical details of the pairing flow can be found in the [Firefox Accounts documentation hub]( 13345 # Device Management Applications that connect to a user's account may register additional information about themselves via a "device record", which allows them to: - customize how they appear in the user's account management page - receive push notifications about events that happen on the account - participate in the FxA "device commands" ecosystem For more details on FxA device registration and management, consult the [Firefox Accounts Device Registration docs]( 10884 8199
fxa_client.udl 42689
internal # Firefox Accounts Client The fxa-client component lets applications integrate with the [Firefox Accounts]( identity service. The shape of a typical integration would look something like: * Out-of-band, register your application with the Firefox Accounts service, providing an OAuth `redirect_uri` controlled by your application and obtaining an OAuth `client_id`. * On application startup, create a [`FirefoxAccount`] object to represent the signed-in state of the application. * On first startup, a new [`FirefoxAccount`] can be created by calling [`FirefoxAccount::new`] and passing the application's `client_id`. * For subsequent startups the object can be persisted using the [`to_json`](FirefoxAccount::to_json) method and re-created by calling [`FirefoxAccount::from_json`]. * When the user wants to sign in to your application, direct them through a web-based OAuth flow using [`begin_oauth_flow`](FirefoxAccount::begin_oauth_flow) or [`begin_pairing_flow`](FirefoxAccount::begin_pairing_flow); when they return to your registered `redirect_uri`, pass the resulting authorization state back to [`complete_oauth_flow`](FirefoxAccount::complete_oauth_flow) to sign them in. * Display information about the signed-in user by using the data from [`get_profile`](FirefoxAccount::get_profile). * Access account-related services on behalf of the user by obtaining OAuth access tokens via [`get_access_token`](FirefoxAccount::get_access_token). * If the user opts to sign out of the application, calling [`disconnect`](FirefoxAccount::disconnect) and then discarding any persisted account data. 9810 # User Profile info These methods can be used to find out information about the connected user. 2497 10242
state_machine # State management These are methods for managing the signed-in state of the application, either by restoring a previously-saved state via [`FirefoxAccount::from_json`] or by starting afresh with [`FirefoxAccount::new`]. The application must persist the signed-in state after calling any methods that may alter it. Such methods are marked in the documentation as follows: **💾 This method alters the persisted account state.** After calling any such method, use [`FirefoxAccount::to_json`] to serialize the modified account state and persist the resulting string in application settings. 2572 # Telemetry Methods This component does not currently submit telemetry via Glean, but it *does* gather a small amount of telemetry about send-tab that the application may submit on its behalf. 1254 # Token Management A signed-in application will typically hold a number of different *tokens* associated with the user's account, including: - An OAuth `refresh_token`, representing their ongoing connection to the account and the scopes that have been granted. - Short-lived OAuth `access_token`s that can be used to access resources on behalf of the user. - Optionally, a `session_token` that gives full control over the user's account, typically managed on behalf of web content that runs within the context of the application. 8886