The following authentication and connection details are generated when you create a mobile backend and are displayed on the mobile backend’s Settings page. Your apps use these details to connect to and authenticate with APIs associated with that mobile backend. These credentials can be used by every application associated with that mobile backend.

• Environment URLs

  • The Base URL is needed for all API calls. This URL is distinct for each environment that you have provisioned.

  • The OAuth Token Endpoint is the URL that your app needs to use to make OAuth token requests.

  • A SSO Token Endpoint is also provided if you enable OAuth and then enable single sign-on (SSO) for your mobile backend. Your app would use this URL to obtain a single sign-on OAuth token in order to login through a remote identity provider.

• A set of Authentication Keys, which your app needs to access APIs through the mobile backend. Keys are generated for both OAuth Consumer and HTTP Basic authentication. Use the toggle switch next to each to enable or disable access through that protocol.

  A set of Access Keys, which your app needs to access APIs through the mobile backend. Keys are generated for both OAuth Consumer and HTTP Basic authentication. Use the toggle switch next to each to enable or disable access through that protocol. For OAuth, you can also enable SSO in order to allow your company’s identity provider to be used authenticate users.

  OAuth Consumer keys are generated in the form of a client ID and a client secret. These two values are unique to this mobile backend.

  HTTP Basic Authentication keys are generated for you in the form of a mobile backend ID and an anonymous key.

  These keys are also unique by environment. When you deploy a mobile backend to a different environment, a new set of keys is generated for the copy of the mobile backend that is added to the target environment.

  If you suspect that these credentials have been compromised (such as by an application handling them insecurely), click Refresh to replace the credentials with new ones or click Revoke to cancel the existing credentials without generating replacements.

  Note:

  Think twice before refreshing or revoking credentials, since these actions will block any calls that any existing apps make through the mobile backend. To get the apps working properly again after credentials have been revoked or refreshed, you need to rebuild the apps with the new credentials and redeploy them.

For details on using the various authentication methods, see Authentication in MCS.

To make it easier to incorporate these details in your apps, use the MCS SDKs for your app platforms. See The SDKs.

All work on mobile backends takes place in the context of an environment. You can use a separate environment for each phase in the mobile backend lifecycle, such as development, testing, and production.

Typically you create a mobile backend in an environment that you have designated for development, publish that mobile backend, and then deploy it to another environment for testing. Once thoroughly tested, you would then deploy the mobile backend to your production environment.

For more on environments, see What is My Environment?.

A realm is the security context for a set of users that defines a set of properties that contain information on the user, such as user ID and user name as well as any custom information that is relevant to the purpose of the apps using that realm.

You can have different realms for different purposes. Each mobile backend in an environment can be associated with only one realm, but multiple mobile backends can be associated with the same realm, allowing them to use a shared set of users and data. When you create a mobile backend, it is assigned to the default realm for the environment.

You can change the realm associated with a mobile backend from the Users tab of the mobile backend. Realms are typically handled by users with the Oracle Cloud identity domain administrator role. If you don’t have that role and you need to change the mobile backend’s realm, contact someone who does have that role. For details on the default realm, see Setting the Default Realm for an Environment.

Even when a mobile backend is configured to allow login through enterprise SSO, it needs a realm that contains records for the users that log in through SSO. In this case, the realm would define only the properties needed to match the user records with those in the identity provider (such as user name or email address).

1. Make sure you're in the environment where you want to work with test users.
2. Click to open the side menu and select Applications > Mobile Backends.
3. Select your mobile backend and click Open.
4. In the left navbar, click Users.

1. Make sure you're in the environment containing the draft mobile backend.
2. Click to open the side menu and select Applications > Mobile Backends.
3. Select your mobile backend and click Open.
4. In the left navbar of the mobile backend, click Storage.
5. Click Select Collections.
6. Start typing the name of the collection that you want to add, select the collection from the drop-down list, and click Select.

You can associate apps with a mobile backend by registering them as clients in MCS and then picking the mobile backend for them to use. In the process, you can also set up notifications profiles for the clients to use. See Client Management for information on registering clients.

If you haven’t yet published your mobile backend, you can change the following things that are associated with the mobile backend at any time:

• Registered clients

• Notifications credentials

• Custom APIs (and their implementations)

• Any connector APIs that are called from custom API implementations

• Storage collections

• User realm

• App policies

Once you have published a mobile backend, its content is frozen. At that point, you would need to create a new version of the mobile backend to make any changes. See Mobile Backend Lifecycle if you are interested in a rundown of publishing, deploying, and versioning mobile backends.