Mobile application configuration
Mobile Applications typically using the Onegini SDK to communicate with an Onegini Token Server instance and need to be configured via the admin console. This section describes the steps related to configuration of these applications.
- Creating a new application
- Removing an application
- Development mode
Creating a new application
In order to create a new application, go to the
Configuration section of the administration console and click the
App configuration tab.
On the overview that is shown you can see all the existing applications.
Note: Applications are meant for mobile applications that are installed on a device that is not managed by you or a trusted party. In general this are your customers' mobile devices. These can be exposed to all kinds of attacks and the application configuration combined with the Onegini SDK provides the necessary protection against that. These clients are also named dynamic clients.
To add a new application click on the add button. The following form will appear:
Fill all the mandatory fields (marked with
* on the form). The other fields are optional.
|Identifier||yes||app1||Unique identifier for this application.|
|Name||yes||My demo application||Display name of this application. This is only used for informational purposes in the Admin console and end-user API.|
|Flows||yes||User authentication||Supported flows for an Application. The available options are explained in a section below.|
|Access token format||yes||Defines whether the Access token is returned as JSON Web Token (JWT) or as Opaque (random) string. Android apps must use SDK version 9.4.0 or higher to work with the JSON Web Token (JWT) format. All iOS SDKs support the JWT format.|
|Redirect URL||yes||Location to which the end-user is redirected after successful authorization. This URI starts with the custom app scheme (e.g. myapp://) and this is the full URI to which the end-user is redirected after they have successfully logged in and given authorization for the requested scopes.|
|Access grant validity||depends||30||Number of seconds an access grant is valid. This is the time an application has to exchange an authorization grant (a.k.a access grant) for an access token. In a common scenario this is done in at most a couple of seconds. Required for flow
|Access token validity||yes||900||Number of seconds an access token is valid. An access token is the temporary key with which an application can fetch resources. When this period has expired the access token has to be refreshed using a refresh token.|
|Resource gateway||no||A mobile app typically uses a resource gateway to fetch data from backend services. Here you can specify the resource gateway which this application will be talking to. It is also used to populate the
|Additional audiences||no||aud1, aud2||A set of case sensitive strings that identifies the audience of the issued access token besides the resource gateways. It is used to populate the
|DUM engine configuration||no||myDumConfig||Configuration of DUM (Delegated User Management) that should be used to gather person report containing information about group memberships and permissions.|
|Default scopes||no||The scopes that are assigned to an authorization request if no scopes are requested. If no scopes are requested by the application in the authorization request and no defaults specified the Token Server will fail the request.|
|Additional scopes||no||The scopes the application is allowed to request apart from the default scopes. The default scopes are also counted as scopes that can be requested by an application.|
|Primary Identity provider||depends||myIdp||The identity provider used when a user authenticates for this application. See the Identity Provider configuration topic for more information on Identity Providers.|
|Additional Identity provider(s)||no||addIdp1, addIdp2||Additional identity providers that can be used when a user authenticates with this application. A primary must be specified if additional are entered.|
|PIN authentication||no||true||Flag to enable authentication via PIN after the user has registered.|
|Registration validity||no||7200||Number of seconds the user registration in the app is valid. The user needs to register again after exceeding that time. Available when
|Fingerprint authentication||no||Flag to enable authentication via Fingerprint for this application after the user has registered.|
|Custom Authenticators enabled||no||Flag to enable Custom Authenticators for this application.|
|Custom Authenticators||no||Configures which Custom Authenticators are allowed for this application. Required if Custom Authenticators are enabled for this application.|
|Implicit authentication enabled||no||Flag to enable implicit authentication for this application. Can be enabled when the registration flow is enabled.|
|Max PIN attempts||yes||3||Max number of times a user can provide a valid PIN before the application is revoked and the user has to authorize the app again. When the value is set to 0 the number of attempts is unlimited.|
|PIN policy||no||my PIN policy||PIN policy that will be used by the mobile application during the PIN creation process. Please see the PIN policy topic|
|Certificates||no||Certificates that are used by the App to establish a secure connection with the Onegini Token Server and other backend systems. The selected Certificates will be part of the configuration file that you can export for your Application.|
|Development mode||no||false||When the development mode is selected the configured application signature is ignored and the developer does not have to configure a new application signature for every new version of the application. To learn more about the application signature check out the Application version management topic.|
|Logo URI||no||URI of the logo for this application, it can be used in for example the consent screen.|
|Template set||no||payment-app/||Every application can have its own branding. Therefore multiple sets of templates are supported. The prefix corresponds to the directory in which a set of templates is stored.|
|Skip Consent page||no||true||In the OAuth flow consent is requested because an application requests access to the user's data. When the application is managed by a third party you may want to notify the user that this application will have access to his personal information. Which information an application has access to is defined by the requested scopes. When consent is disabled the user is not required to give consent for the application during the authorization process.|
|Skip Authorization complete page||no||If the registration for the mobile app is handled in the browser, it is highly recommended to show a page in the browser before you send the user back to the app. This page serves two purposes: you can inform the user that they are going back to the mobile app, and you can prevent that the browser tries to open the app later. Without this page, the user would be asked to open the mobile app when they open the browser later again. When enabled, this page will be shown both when the registration has succeeded and when the registration has failed because caused of explicit user interaction, for example when they have canceled the authentication. The authorization complete step will not be triggered when the error is caused by misconfiguration or an invalid authorization request (e.g. passing an invalid identity provider identifier, invalid OpenID Connect (OIDC) parameters for
Additional information about the configuration of a Pin policy, a Resource gateway, Scopes and an Identity provider can be found in separate chapters.
Additional Identity provider(s) is handled by the SDK. Refer to the
iOS SDK or Android SDK documentation for help with adding support for multiple Identity Providers.
Description of flows
Flows can be configured for an Application.
|User registration||Specifies whether an application can use the OAuth authorization code grant type in order to allow this application to request an access token on behalf of the end-user.|
|Anonymous resource calls||Specifies whether an application can use its client credentials to request an access token. Note that this access token is not linked to a user since it's solely requested by the application without any user interaction. This function is typically used to fetch resources before the user has authenticated.|
Removing an application
In order to remove an application, Go to the
Configuration tab of the administration console. On the list of applications find the one you want to remove and
click on the delete button on the right (You will be asked to confirm you decision).
Please note that you cannot remove an application that is already in use. In use means there are already registered clients using this application. An alternative could be to disable all application versions so the application cannot be used anymore.
Each and every application communicating with the Token Server must identify itself. The application needs to tell the Token Server its version, platform and the application identifier. Based on this input the application is challenged to proof his identity. An application can proof its identity by using a shared application signature which is known on both the server and client side. This Application signature is different for each application, platform and version combination. The Onegini SDK is responsible for providing the Application signature since it depends on the application itself. Hence, the Application signature is different for each build of the application and can change frequently during development. This is very secure, however it is not very convenient for app developers who need to register a new application signature for the specific application version they are using before they can start testing their app again. To prevent slowing down the development process, an application can be put in development mode. By enabling the development mode, an application no longer has to prove its identity.
Note: Payload encryption also requires an identified app but cannot be bypassed by enabling development mode.
Enabling development mode
Development mode must never be enabled in a production environment. To prevent accidentally enabling the feature, two actions are required to enable it. First of all the development mode should be enabled in the technical configuration using a Docker Compose environment variable.
When the development mode is enabled in the technical configuration it can also be enabled in the functional configuration using the admin console. You can specify per
application if development mode must be enabled for this application. In the application overview
applications using the development mode are marked with a warning icon, indicating the development mode is enabled.
In the screenshot below you can see that the
TestClient application is running in development mode.
Warning: Enabling development mode in production can severely reduce the security of the Mobile Security Platform. This features is only for convenience on development or test environments. Hence, development mode is turned off by default.