10 Setting Up Authentication

This chapter explains how to configure authentication in the Oracle Backend for Firebase Console so your apps can sign users in and receive tokens. It covers BASIC, LDAP, and IDCS setup, plus social sign-in, email verification, password policy, and provider changes.

Parent topic: Authentication

10.1 Prerequisites

  • You have an Oracle Backend for Firebase project created in the Console.

  • You understand that each project uses one authentication type, and all apps in the project share it.

Parent topic: Setting Up Authentication

10.2 Enabling Authentication for a Project

Enable authentication to turn on identity services for the project so apps can sign users in and receive tokens.

  1. Open the Console and select your project.

  2. Open the Authentication section on the left hand side of the screen.

  3. Click Set up authentication.

Figure 10-1 Authentication Setup

Authentication Setup

Parent topic: Setting Up Authentication

10.3 Basic Authentication Setup

Use BASIC authentication for development or testing. It supports email and password sign-in and the third-party sign-in methods listed in Basic Authentication.

Setup Steps

  1. Open Authentication.

  2. Select Authentication setup.

  3. Choose Basic.

  4. Save and apply the configuration.

Optional Settings:

  1. Configure Password Policy:

  2. Configure SMTP for email verification and password reset.

  3. Save and apply the configuration.

See Also:

Parent topic: Setting Up Authentication

10.4 LDAP Authentication Setup

Use LDAP authentication when your organization already manages users in LDAP and wants centralized user storage. Oracle Backend for Firebase does not install LDAP for you. It connects to your existing LDAP server during setup.

  1. Open Authentication.

  2. Select Authentication setup.

  3. Choose LDAP.

  4. Enter the LDAP connection details:

    • Auth hostname: LDAP_HOST

    • Auth port number: LDAP_PORT

    • LDAP directory DN" LDAP_USER_DIR

    • LDAP directory admin username and LDAP directory admin password.

  5. Save and apply the configuration.

    Figure 10-2 LDAP Authentication Configuration

    LDAP Authentication Configuration

Optional Settings

  1. Configure Password Policy.

  2. Configure SMTP for email verification and password reset.

See Also:

Parent topic: Setting Up Authentication

10.5 IDCS Authentication Setup

IDCS lets you use an OCI IAM Domain as the authentication server for your Oracle Backend for Firebase project.

To integrate IDCS, you need:

  • Domain URL - the HTTPS URL of an Oracle Identity Domain (See Creating an Identity Domain) you administer. The URL must use HTTPS, point to a plain Oracle Identity Domain (for example, https://<identity-domain>.identity.oraclecloud.com), and contain no path, query string, fragment, or embedded credentials.

  • Access token with Identity Domain Administrator privileges

To obtain an access token:

  1. Create a confidential application (See Adding a Confidential Application) in your domain with the Client Credentials grant type and the Identity Domain Administrator app role.

  2. Request an access token (See Access Token) using the application's client ID and client secret.

Oracle Backend for Firebase uses this token once, during setup, to configure the target domain on your behalf.

See Get Started with Oracle Identity Cloud Service for more information about setting up IDCS.

  1. In the Oracle Backend for Firebase Console, select Authentication and choose IDCS.

  2. Enter the domain URL and access token.

  3. Save the configuration.

Figure 10-3 IDCS Authentication Configuration

IDCS Authentication Configuration

After Save

Your Oracle Identity Domain acts as the identity provider for this project. End users authenticate against IDCS, and the Fusabase SDK consumes the tokens IDCS issues.

For the SDK calls that initiate authentication, see Authentication SDK Reference.

WARNING:

  • Switching authentication modes does not migrate users. If you change a project from Basic or LDAP to IDCS (or conversely) after users have signed up, those accounts will not be carried over. Users must recreate them under the new mode.

  • Re-running IDCS setup is destructive. Saving IDCS configuration again replaces the previously provisioned IDCS applications and self-registration profile for this project.

Parent topic: Setting Up Authentication

10.6 Setting Up Third-Party Identity Providers

You can let the application users authenticate with Oracle Backend for Firebase using different social accounts such as Google, Facebook and Github. These are integrated through OAuth2 flows and managed through custom LDAP and IDCS setups. You can also integrate any Identity Platform that supports OIDC or SAML protocol like Auth0, Okta, and so on.

Parent topic: Setting Up Authentication

10.6.1 Set up Social Sign-in (GitHub, Google, and more)

  1. In Google Cloud Console, open APIs & Services and then Credentials.
  2. Select Create credentials, and then create an OAuth client ID.
  3. Set Application type to Web application, and enter an app name.

  4. Add the Oracle Backend for Firebase OAuth redirect URI to the Authorized redirect URIs list.

  5. Save the client and copy the Client ID and Client Secret.

  6. In the Oracle Backend for Firebase Console, enable Google, and enter the client ID and client secret.

On the Facebook for Developers site, get the App ID (Client ID) and an App Secret (Client Secret) for your app.

Enable Facebook Login:

  1. Open the Sign-in Method in the Authentication Section.
  2. Enable Facebook and specify Client ID and Client Secret you got from Facebook.
  3. Make sure the OAuth Redirect URI in the Console is listed as OAuth Redirect URIs in the Facebook App's settings page on the Facebook for Developers site in the Product Settings > Facebook Login config.

Enable Github Login:

  1. Register your app as a developer application on GitHub and get your app's OAuth 2.0 Client ID and Client Secret.
  2. Open the Sign-in Method in the Authentication section.
  3. Enable Github and specify Client ID and Client Secret you got from Facebook.
  4. Make sure the OAuth Redirect URI in the Console is set as your Authorization callback URL in your app's settings page on your GitHub app's config.

Parent topic: Setting Up Third-Party Identity Providers

10.6.2 Configuring Enterprise Identity Protocols

Oracle Backend for Firebase supports enterprise authentication through:

  • Open ID Connect

  • SAML

To sign in users using an OIDC provider, you must first collect the following information from the provider:

  • Client ID: A string unique to the provider that identifies your app. Your provider might assign you a different client ID for each platform you support. This is one of the values of the aud claim in ID tokens issued by your provider.

  • Client secret: A secret string that the provider uses to confirm ownership of a client ID. For every client ID, you will need a matching client secret. (This value is required only if you're using the auth code flow, which is strongly recommended.)

  • Issuer: A string that identifies your provider. This value must be a URL that, when appended with /.well-known/openid-configuration, is the location of the provider's OIDC discovery document. For example, if the issuer is https://auth.example.com, the discovery document must be available at https://auth.example.com/.well-known/openid-configuration.

After you have the aforesaid information, enable OpenID Connect as a sign-in provider for your Oracle Backend for Firebase project:

  1. On the Sign-in Method page in the Authentication Section, click Add new provider, and then click OpenID Connect.
  2. Give a name to the provider. The provider ID that's generated is something like oidc_example. You'll need this ID when you add sign-in code to your app.

  3. Specify your client ID and client secret, and your provider's issuer string. These values must exactly match the values your provider assigned to you.

  4. Make sure the OAuth Redirect URI in the Console is set as one of the OAuth Redirect URIs in the sign-in provider app's config.

To sign in users using a SAML identity provider, you must first collect some information from the provider:

  • The provider's Entity ID: A URI that identifies the identity provider.
  • The provider's SAML SSO URL: The URL of the identity provider's sign-in page.
  • The provider's public key certificate: The certificate used to validate tokens signed by the identity provider.

After you have the aforesaid information, enable SAML as a sign-in provider for your Oracle Backend for Firebase project:

  1. On the Sign-in Method page in the Authentication Section, click Add new provider, and then click SAML.
  2. Give a name to the provider. The provider ID that is generated is something like saml_example. You'll need this ID when you add sign-in code to your app.
  3. Specify your identity provider's entity ID, SSO URL, and public key certificate. These values must exactly match the values your provider assigned to you.
  4. Add the SAML Provider's domain to the Authorized Origins in Oracle Backend for Firebase Console.
    • Example: http://dev-urnsds934nlkln.auth0.com should be set as an Authorized Origin if this is your SAML Provider.
  5. Make sure the Assertion Consumer Service URI in the Console is set as the Assertion Consumer Service URI in the SAML provider app's config.
  6. Ensure the Audience, Destination, Recipient and NameID is correctly set in the SAML Provider's Configuration / Settings.
    1. Audience: Available on the Oracle Backend for Firebase Console UI when enabling the provider
    2. Destination: Same as the Assertion Consumer Service URI.
    3. Recipient: Same as the Assertion Consumer Service URI.
    4. NameID: Must ensure that the mapping is to a valid Email address. For example:
      "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
"nameIdentifierProbes": [
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn",
    "email"    
],

"mappings": {
    "email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
     ...
},
...

Parent topic: Setting Up Third-Party Identity Providers

10.7 Configuring SMTP for Email Verification and Password Reset

You can send an address verification email to a user or an email to reset their password. Oracle Backend for Firebase Console UI shows the list of users whose email is not verified. There you also get the option to send the email for Address Verification / Reset Password. The email contains a One Time Code to validate the intended operation.

For Oracle IDCS as Authentication server, Oracle IDCS uses its own email service to send these emails. From the IDCS console, you can also customize the email sent for these operations.

For BASIC / LDAP, you must set up the SMTP server credentials to enable the email service. Following details are needed to successfully set the SMTP server with the Oracle Backend for Firebase Infrastructure.

smtp_host SMTP Server Host
smtp_port SMTP Server Port
smtp_auth_username Username to login to SMTP server
smtp_auth_passkey Password to login to SMTP server
default_from The sender of the email
connection_type SSL / TLS
wallet_path Wallet path for Secure connection and SSL certificates

Console Steps

Note:

This setup is essential for BASE and LDAP users using email/password login flows described in:

  • User Lifecycle Management → Email Verification

  • User Lifecycle Management → Password Reset

  1. In the Console, navigate to the Project Settings > SMTP Settings.

    Figure 10-4 SMTP Settings

    SMTP Settings

  2. Enter the following:

    • SMTP server hostname and port

    • Authentication credentials

    • Sender email address

  3. Save the configuration.

Parent topic: Setting Up Authentication

10.8 Configuring OIDC and SAML Identity Providers

Oracle Backend for Firebase supports user sign-in using external identity providers through both OpenID Connect (OIDC) and SAML. OIDC and SAML federation is bidirectional: you supply values from your identity provider to Oracle Backend for Firebase, and Oracle Backend for Firebase returns a callback URI that you must register back with your identity provider. Keep both consoles available while you complete setup.

Configure an OpenID Connect (OIDC) Provider

To sign in users using an OIDC provider, you must first collect the following information from the provider:

  • App ID: the client identifier issued by your identity provider for this application.

  • App secret: the matching client secret. Required for the authorization code flow.

  • Issuer (URL): your identity provider's issuer URL. Appending /.well-known/openid-configuration to this URL must return the provider's OIDC discovery document. For example, an issuer of https://auth.example.com requires https://auth.example.com/.well-known/openid-configuration to be reachable.

Set Up in the Console

  1. In the Oracle Backend for Firebase Console, open your project and select Authentication.

  2. Add a new provider and choose OIDC. The Enable OIDC dialog opens.

  3. Enter a Name, then paste the Issuer (URL), App ID, and App secret.

  4. Toggle Enable on.

  5. Click Save.

Complete the loop on your identity provider:

  1. In the OIDC dialog, click Copy URI to copy the OAuth redirect URI shown by the Console.

  2. In your identity provider's application settings, add that URI to the list of allowed redirect URIs.

Until both sides of this loop are configured, sign-in attempts will fail.

Configure a SAML 2.0 Provider

To sign in users using a SAML identity provider, you must first collect the following information from the provider:

  • Entity ID: a URI that identifies the identity provider.
  • SAML SSO URL: the URL of the identity provider’s sign-in page.
  • Public Key Certificate: the certificate used to validate SAML assertions signed by the identity provider.

After you have the above information, enable SAML as a sign-in provider in the Oracle Backend for Firebase project Console:

  1. In the Oracle Backend for Firebase Console, open your project and select Authentication.

  2. Add a new provider and choose SAML. The Enable SAML dialog opens.

  3. Enter a Name, then paste the Entity ID, SSO URL, and Certificate.

  4. Toggle Enable on.

  5. Click Save.

  6. Add the SAML provider's domain to the Authorized Origins list in your project's Authentication settings.

Complete the loop on your identity provider:

In your SAML identity provider's application settings, configure the following:

  • Assertion Consumer Service (ACS) URI: copy from the SAML dialog in the Console using Copy URI.
  • Audience: copy from the SAML dialog.
  • Destination and Recipient: set both to the ACS URI.
  • NameID: must map to a valid email address. Oracle Backend for Firebase uses the user's email to identify and link the federated account. A SAML assertion without a valid email NameID will be rejected.

Use the provider from your app:

After saving, the Console shows the provider in the providers list with a generated ID of the form oidc_<name> or saml_<name> — for example, a SAML provider named example appears as saml_example. Pass that exact string to your SDK's federated sign-in API. 

import { getAuth, signInWithPopup, OAuthProvider } from "fusabase/auth";

const auth = getAuth(app);
const provider = new OAuthProvider("oidc_example");
const result = await signInWithPopup(auth, provider);

For SAML, use SAMLAuthProvider with a saml_* provider ID. signInWithRedirect(auth, provider) is also available if you prefer a full-page redirect over a popup. 

import com.oracle.mobile.fusabase.auth.FusabaseAuth;
import com.oracle.mobile.fusabase.auth.OAuthProvider;

FusabaseAuth auth = FusabaseAuth.getInstance();
OAuthProvider provider = OAuthProvider.newBuilder("oidc_example").build();

auth.startActivityForSignInWithProvider(activity, provider)
    .addOnSuccessListener(authResult -> {
        // Signed in
    });
import FusabaseAuth

let provider = OAuthProvider(providerID: "oidc_example")
let credential = try await provider.getCredentialWith()

For SAML, use SAMLAuthProvider(providerID: "saml_example"). getCredentialWith() runs the full flow and persists the resulting session to Keychain — no additional signIn(...) call is required.

Parent topic: Setting Up Authentication

10.9 Defining Password Policies

Password policies apply to Basic and LDAP users and are enforced during sign-up and password reset.

Use a password policy to align with your organization’s security requirements.

Configurable Attributes:

Setting a password policy can improve account security by enforcing password complexity requirements. Password Policy support the following password requirements:

  • Lowercase character required

  • Uppercase character required

  • Numeric character required

  • Non-alphanumeric character required

  • Password length (ranges from 6 to 30 characters; defaults to 6)

Console Steps

  1. In the Console, open Authentication , and then Password Policy.

    Figure 10-5 Password Policy Settings

    Password Policy Settings

  2. Set the policy requirements (length, uppercase, lowercase, numeric, special characters).

  3. Save the policy.

Parent topic: Setting Up Authentication

10.10 Changing Authentication Providers

You can switch the authentication provider for a project. This affects all apps in the project.

Note:

If you switch from BASIC or LDAP to IDCS (or from IDCS to BASIC or LDAP), Oracle Backend for Firebase does not migrate user accounts. Users must create new accounts under the new provider. For application users, this means they will lose access until they sign up again, and any account links tied to the old provider will no longer work. This happens because IDCS and BASIC/LDAP manage identities separately, and Oracle Backend for Firebase does not copy or map identities between them.

Plan this change carefully because users might need to sign up again after the switch.

Before you change the provider:

  • Plan for users to sign up again under the new provider.

  • Configure SMTP again if the new provider requires it.

Parent topic: Setting Up Authentication

10.10.1 Switching Authentication Providers

  1. Log in to the Oracle Backend for Firebase Console.

  2. Navigate to your project.

    From the dashboard, select the project for which you want to change the authentication provider.

  3. Open the Authentication Settings.

    • In the left-hand navigation panel, click on Authentication.

    • You can see the current authentication provider listed (For example, BASIC, LDAP, IDCS).

  4. Click Manage Configuration.

    Note:

    This button is available only to users with the OWNER or DEVELOPER role for the project.

  5. Select the New Provider.

    Choose from the following:

    • Basic: No external setup required.

    • LDAP: Requires LDAP host, port, admin DN, password, and user directory.

    • IDCS: Requires domain URL, client ID, and client secret.

  6. Enter the configuration details:

Parent topic: Changing Authentication Providers

10.11 Setting Up and Managing Authentication Using CLI

Prerequisite

Ensure that the setup of CLI for Oracle Backend for Firebase is complete.

See Also:

Configure the CLI for detailed steps on how to set up the CLI for Oracle Backend for Firebase

Set Authentication

The following command configures authentication for the current project:

fusabase set-auth --path=<path-to-authConfig.json>

Login

fusabase login <clientId>:<clientSecret>

Initialize Session

The following command builds a user access token.

fusabase init

Note:

Tokens have expiry and may need to be refreshed.

Authentication Management

  • List Users: 
    fusabase auth list --export=<filepath>
     fusabase auth list --filter=<criteria> --export=<filepath>
  • Add a User: 
    fusabase auth add --path=<config>
  • Remove a User: 
    fusabase auth delete --username=<username>
  • Disable/Enable a User: 
    fusabase auth disable --username=<username> --disable=<true/false>
  • Manage Sign-in Methods: 
    fusabase auth sign-in-method <google|facebook|epw|github>
    fusabase auth sign-in-method <provider> --path=<config>
  • Get Provider Details: 
    fusabase auth get <provider>

Parent topic: Setting Up Authentication

10.12 Authorized Domains

Authentication APIs are protected through CORS enforcement for web SDK usage. Operations such as signIn, signUp, updateProfile, and all social login flows (Redirect, Popup, and Manual) are restricted to authorized frontend domains only.

You can use the Console UI Project Settings to add or remove existing authorized domains.

Figure 10-6 Authorized Domains

Authorized Domains

Authorized Frontend Domains Protect Web SDK Authentication Calls

When a browser application uses the web SDK to call authentication APIs such as signIn, signUp, or updateProfile, the request must originate from a frontend domain that has been authorized for the application. This prevents an untrusted website from embedding the SDK, reusing a copied project configuration, and making browser-based authentication calls against the same backend.

Social Sign In Redirects Return Only to Trusted Application Origins

In a redirect-based social login flow, the user temporarily leaves the application to authenticate with an identity provider such as Google, GitHub, Facebook, an OIDC provider, or a SAML provider. After the provider completes authentication, the service does not blindly return the result to any URL supplied by the browser. The application context/origin is checked against the configured authorized frontend domains before the flow is allowed to continue.

Popup Social Login Posts Results Only to the Initiating Application Origin

For popup-based social login, the authentication result is returned to the opener window using browser messaging. The target origin is derived from the original application context and normalized before the message is sent. This keeps the response scoped to the trusted application origin rather than broadcasting it broadly.

For example, a popup opened by https://app.example.com receives its result through a message targeted to that origin. A different site cannot simply open the same flow and receive the result unless its origin is also authorized.

Manual Token Exchange Is Still Domain-Gated for Browser Usage

Manual or token-based social login flows also go through the same browser-facing CORS allowlist. Even when the frontend already has a provider token, the backend exchange that registers, signs in, or links the user is available to browser applications only from authorized frontend domains.

This helps prevent copied SDK configuration or exposed public project identifiers from being used by arbitrary websites to perform social login operations from the browser.

Parent topic: Setting Up Authentication