Authenticating Application Users

Application users (app users) are the people or systems that sign in to your app and call Oracle Backend with Firebase APIs services through the SDKs or REST APIs. This chapter explains what an app user is, how sign-in works, and how tokens and user state behave so you can design predictable Auth flows.

Happy path: Enable a sign-in method in the Console, call the SDK sign-in method in your app, and listen for Auth state changes to keep your UI in sync. For a basic example, see Getting started with authentication.

Authentication answers two questions for every request:

  1. Who is the caller?

  2. Is the caller signed in?

Oracle Backend with Firebase APIs uses authentication tokens to identify the signed-in user and to keep requests tied to that user across SDK calls.

App Users

An app user represents a user account that has signed up for an app in your project. Apps in the same project share a single Auth user database, so a user can sign in to multiple apps in that project with the same account.

Basic Properties

Each registered user has a fixed set of properties stored in the Auth service:

You cannot add arbitrary properties to the user object itself. Store app-specific data in your database and reference it by user ID.

Sign-In Methods

Oracle Backend with Firebase APIs supports multiple sign-in methods, so you can match your app’s needs and your users’ identity provider:

Oracle Backend with Firebase APIs integrates federated identity flows. It does not manage the identity provider login UI, so your app redirects to the provider for sign-in and returns with credentials.

For details on BASIC and LDAP, see Authentication methods: BASIC and LDAP.

Authentication Flow

This is the end-to-end flow that Oracle Backend with Firebase APIs manages when a user signs in, providing insight into the behind-the-scenes process.

  1. The user signs in through the SDK using a supported method.

  2. Oracle Backend with Firebase APIs validates the credentials.

  3. The service issues an access token and a refresh token.

  4. The SDK stores the tokens and attaches the access token to requests. You do not need to manage tokens directly unless you are calling the REST APIs.

  5. When the access token expires, the SDK uses the refresh token to get a new access token.

  6. When the user signs out, the SDK clears local state and the refresh token is invalidated.

Current User and Auth Listeners

When a user signs in, the SDK sets the current user and keeps that state based on your SDK configuration. You can keep Auth state in memory, local storage, or IndexedDB. Client SDKs provide Auth listener callbacks so your app can respond to changes in Auth state.

Listeners are notified when:

Application User Self-service

The client SDKs give you simple, user-facing actions you can surface in your app:

Use these methods to build self-service flows inside your app, such as a profile page or account settings screen. It keeps users in control of their accounts and reduces the need for manual admin support.

Email Verification and Password Reset

Email verification and password reset help you build a smoother onboarding and recovery experience. These features are available for BASIC and LDAP users and require SMTP configuration.

SMTP Configuration

Before you turn the email verification and password reset features on, make sure you have access to an SMTP server. Oracle Backend with Firebase APIs connects to your SMTP server to send emails; it does not provide one. Gather the SMTP host, port, sender email address, and credentials so you can enter them in the Console. If you do not have an SMTP server, use your organization’s mail service or a third-party SMTP provider.

Configure the SMTP server in the Console:

  1. Open Authentication in the Console.

  2. Enter the SMTP host, port, sender email, and credentials.

  3. Save the configuration.

Email Verification

Email verification confirms that the user’s email address is valid. This helps you detect typos and prevents users from signing up with addresses they do not control.

How it works:

Password Reset

Password reset lets users recover access when they forget their password, so you do not need to handle manual resets.

How it works:

Password reset is not supported for social login users. It is supported for IDCS users.

Auth Tokens

Oracle Backend with Firebase APIs issues tokens when users sign in, and the SDKs attach the right token to each request for you. You usually do not need to handle tokens directly unless you are calling the REST APIs or troubleshooting a sign-in issue.

You can encounter these token types:

Auth Token Example

{
  "user_displayname": "Scott Scott",
  "user_id": "68AB1C234D9FA873E083F283695E41B0",
  "email_verified": "true",
  "creation_time": "2024-07-20T10:25:36.789123Z",
  "claim": null,
  "idp_type": "BASE",
  "sub": "scott@example.com",
  "iss": "baas_onprem#68AB1C2DE7C3D871E083F283695E54A2",
  "iat": 1721462736,
  "exp": 1721466337,
  "idp_name": "UserNamePassword",
  "scope": "database auth storage",
  "aud": "68AB1C2A90EF1872E083F283695E51D3",
  "uid": "68AB1C234D9FA873E083F283695E41B0",
  "token": {
    "email": "scott@example.com",
    "email_verified": "true",
    "sub": "scott@example.com",
    "name": "Scott Scott"
  }
}

Auth Token Fields

Managing Application Users

Use the Console to view users and inspect provider and verification status. This is useful when you are testing sign-in flows or supporting users. If you need to disable or delete users, do so from the Console.

JSON Web Key

Oracle Backend with Firebase APIs projects issue JSON Web Tokens (JWTs) for authentication to Oracle Backend with Firebase APIs services. These tokens are signed using the RS256 algorithm. To enable resource servers to validate these tokens, each project exposes its public signing key as a JSON Web Key (JWK).

The Console UI allows you to copy the project’s current JSON Web Key for use in application middleware or other token verification components. However, it is recommended to retrieve the signing key from the JWK endpoint (URL) instead of using a manually copied key. This ensures that applications always use the latest public key, particularly when key rotation occurs.

Key Rotation

The Console UI provides a Rotate Key option that enables a project to replace its signing key. Key rotation may be performed:

After a key rotation, applications that retrieve the JWK from the endpoint automatically receive the updated public signing key.

JWK Endpoint

Use the following endpoint to retrieve the JSON Web Key for a project:

<HOST>/ords/<schemaAlias>/_/baas-services/idm/signingKey/<project_id>/jwk