Last updated

Operator Application Implementation Example

On this guide we present a full implementation example of an operator application, step by step.

Overview

End UserMobile ApplicationOperator ServerOBH Identity ProviderOBH SDKOBH HelmetLaunches the application and authenticatesRequests an access token (authentication)Generates the token via the OAuth flowReturns the generated tokenSends the valid tokenTransmits the secured tokenScans for nearby mountsSends scan results via the bleEngineState streamConnects to the mountEstablishes BLE connectionPerforms an action (e.g., association, unlocking the helmet)Forwards the action requestValidates the access request with permissionsAuthorization confirmedExecutes the requested action (e.g., association, unlocking the helmet)Returns the action resultSends an event in the deviceState streamEnd UserMobile ApplicationOperator ServerOBH Identity ProviderOBH SDKOBH Helmet

Implementation process

1. Initial Authentication

  • The end user opens the mobile application to authenticate.

2. Obtaining an OBH Access Token

  • The mobile application requests an OBH access token from the operator server.
  • The operator server contacts the OBH Identity Provider using OAuth standards to generate a secure token.
  • The token must have a restricted scope tied to a single mount to secure the operator's account.
  • The generated token is returned to the mobile application via the operator server.
curl --request POST \
  --url https://auth.obh-mobility.com/oauth/v2/token \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --data grant_type=client_credentials \
  --data 'scope=openid profile sub urn:zitadel:iam:org:project:id:272428514190297504:aud role:restricted mount:OBH-' \
  --data client_id=fake-company \
  --data client_secret=QftVrBgfBtrPrRPaz7pQUHDl6wfQ80hnVmtodRtgty6reDjNjFosg1YnATtYimVWo

Learn more about how to generate a token on this page.


3. Transmitting the Token to the SDK

  • The mobile application sends the generated token to the OBH SDK, which will be used for all interactions with the OBH system.
await ObhFlutterSdk.instance.setAuthCredentials(
    token,
    'https://api.dev.obh-mobility.com/api/v1',
);

4. Searching for an OBH Device (Optional)

Depending on the scenario, searching for a nearby mount may be useful.

  • The mobile application triggers a scan by instructing the OBH SDK to detect nearby mounts.
  • The SDK performs the scan and returns the list of detected available devices to the mobile application.
// Listen to scan results
ObhFlutterSdk.instance.getBleEngineStateEventStream().listen((event) {
  if (event is ScanResultEvent) {
    // Update UI with event.devices
  }
});

// Start scan (e.g., 10s timeout)
ObhFlutterSdk.instance.scanObhDevices(10000);

5. Connecting to the Mount

We recommend storing the information about which mount UID is installed on which vehicle.
This way, a connection can be established directly using the UID.

  • The OBH SDK establishes the necessary communication to enable interactions with the system.
await ObhFlutterSdk.instance.connectDevice(uid);

6. User-Initiated Action

  • The user initiates an action (e.g., unlocking a helmet) in the application.
  • The SDK contacts the OBH Identity Provider to validate permissions and authorize the action on the mount.
  • If the request is validated, the SDK sends the command to the OBH mount via the BLE connection to execute the requested action.
await ObhFlutterSdk.instance.unlockHelmet(uid);

7. State Monitoring

  • All mount states are reported through the stream accessible via getDeviceStateEventStream.
  • Helmet presence and handle status can be used to verify actions on the mount.
ObhFlutterSdk.instance.getDeviceStateEventStream(uid).listen((event) {
    print("Event: $event");
});