Android Mobile App

An Android Mobile App is software that runs on a handheld device (phone, tablet, e-reader, iPod, etc.) than can connect to WIFI or wireless carrier networks, and has an operating system that supports standalone software.

Creating an App:

1. Go to Administrator dashboard -> Apps -> “App Settings”.

2. Click “Create New App” button.

3. Click “Create App” button, the app details screen displays

4. Enter app name and click “Android Mobile App”

App Details

This is where all the basic information about your application such as app name, app type, redirect URLs, allowed logout URLs, website, logo, company details, etc. are entered.

Note * mark fields are mandatory.

5. Enter App name, for example: Televisions (your business name)

6. Enter App logo URL, for example: This logo will appear in several areas, including the list of applications in the Dashboard, as well as things like customized consent forms.

7. Administrator can change the App type from Android Mobile App, to any other app type(IOS Mobile App, Windows Mobile App and Single Page WebApp).

8. Select scope from drop down, cidaas provides Default Scopes. To define new scopes refer Scope Management.

9. Click on the _hyperlink _to Import scopes from scope groups, as in the below screen. For more information click Scope Groups.

Reference Link What is Scope

10. Select hosted page group from drop down. By default, cidaas provides Hosted Pages.

11. Enter redirect URL: The URL of the landing page. Once the user is successfully authenticated, he is redirected to this URL. User can specify multiple valid URLs here, separated by whitespace (typically to handle different environments such as QA or testing).

Reference Link What is Redirect URL?

12. Enter Allowed Logout URLs - User can specify multiple valid URLs here. This is where the user is redirected to after logging out.

Company Details

Enter company details here.

13. Company Name: Enter details here to store the company name which is to be displayed while using this app.

14. Company Address: Enter company address that is to be displayed while using this app.

15. Website URL: Provide the business site URL.

16. Terms and Conditions URL: This link will be rendered automatically in login/registration pages, if the Terms URL is configured.

17. Privacy Policy URL: This link will be rendered automatically in login / registration pages, if the privacy policy URL is configured.

Advanced Settings

In addition to above, cidaas allows you to configure few options for OAuth, Token payloads, social login providers.

OAuth Settings

These settings should be configured to define OAuth response types and origins

1. Click on the “Show Advanced Settings” to view a similar screen

2. From the drop down select response types checkbox (multiple checkbox can be selected)

3. From the drop down select grant types checkbox (multiple checkbox can be selected)

4. Enter the allowed origins and allowed web origins.

Token Settings

5. From the drop down select Additional Access Token Fields checkbox (multiple checkboxes can be selected)

Note You can configure expiry time for Access Tokens and ID Tokens as needed. The default value set is 86400 seconds (one day).

You can upload or define your consent policy, that you would like to show to your end user. There may be multiple policies that you want to show based on context.

Cidaas provides you a Consent Management framework that allows for this, including feature to maintain multiple versions of same policy.

By default, cidaas has a standard template that is displayed to your end users.

6. From the drop down select created consent group, as in the below screen

How to create Consent forms/groups.

Miscellaneous Settings

You can manage security settings such as allowed providers, required fields and 2FA settings here.

7. From drop down select allowed providers (multiple checkbox can be selected)

8. Registration Fields: From the drop down select allowed fields and required fields (multiple checkboxes can be selected) these fields are comes from the enabled registration fields.

Note what every mentioned on the allowed fields that fields only can display on the registration page if don,t specified allowed fields in app level by default taken enabled regitsrtation fields from the registration setup.


9. While registering new user's must verify their identity through the SMS or Email based upon the app level administrator can enable this option.

10. Administrator can enable the captcha and password policy in app level.

11 . Always ask for 2FA:When this option is enabled at the app level, the end-users will be required to verify their identity using the 2nd authentication factor.

For more information refer Always ask for 2FA

12 . Click “Save” button.

Find the below advanced settings table for reference:

Fields Description
OAuth Settings
Response Types Response Type: The response type specifies the Response Type you want to use. This can be either code or token or ID token. The client constructs the request URI by adding the following parameters to the query component of the authorization endpoint URI: cidaas provides the following default Response Types, while creating the App:
Code: The Authorization Code grant type is used by confidential and public clients to exchange an authorization code for an access token. After the user returns to the client via the redirect URL, the application will get the authorization code from the URL and use it to request an access token.
Token: When the response type is specified as "token", the access token is directly issued.
Id_token: Id Token is issued only when the App has OpenID scope. The id_token issued is in the format of JWT token (JSON Web Token) - which is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message. .
Grant Types Grant Type is the mechanism in which an application can get access token. Cidaas supports several Grant Types of OAuth 2.0 protocol. These are available for use while creating different type of apps (Andriod / iOS / Windows mobile / Web / Client / Device). cidaas provides the following default Grant Types, while creating the App: Implicit/ Authorization Code/ Password/ Refresh Token.
Implicit Grant: Implicit Flow is typically for Single Page App. The implicit grant type is used to obtain access tokens for public clients known to operate using a redirection URI. These clients are typically implemented in a browser using a scripting language such as JavaScript. Typical flow is with an application opening a browser to show authorization server. When user approves request from app, they are rediregted back to application with access token.
Authorization Code: When you use this option, the application gets back an authorization code from resource owner, which in turn is used by application to get an Access Token from cidaas authorization server. Typical use cases are for browser based applications, mobile applications and apps on a web server.
Password: You can use this grant type if your application wants to use a classical login style, where end user has registered a username and password with cidaas. Login page will be cidaas app login screen. The password is used directly as an authorization grant to obtain an access token.
Refresh Token: Refresh tokens are credentials used to obtain access tokens. Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires, or to obtain additional access tokens with identical or narrower scope.
Client Credentials: is used as a grant type when an application wants to access its own resources (like icons, user statistics or web url) and not particular resource of a user.
Device Flow: The Device Flow is an OAuth 2.0 extension that enables devices with no browser or limited input capability to obtain an access token.
Allowed Web Origins Use this when you want to embed cidaas login in your web app using iframe. You can enter all the various URLs from where a cidaas login page is shown in an iframe. User can specify multiple valid URLs here, separated by whitespace. By default all domains mentioned in “Redirect URLs” (attribute entered in App settings) is allowed.
Allowed Origins Typically, the same-origin policy in web browsers prevents JavaScript from making requests across domain boundaries. To work properly, many web apps need a mechanism for implementing cross-domain requests. For example, to call your own Web APIs and Cidaas APIs without same-origin policy errors, CORS introduces a standard mechanism that can be used. The CORS spec defines a set of headers that allow the browser and web server to communicate about which requests are allowed. This field here maps to CORS Header Field ‘Access-Control-Allow-Origin’. User can specify multiple valid URLs, separated by whitespace.
Token Settings
Additional Access Token Fields Admin user can specify the additional fields (defined in the Registration setup) that will be appended to the access token. For more information refer Access Token Payload
Misc. Settings
Allowed Providers Having popular social providers such as Facebook or Google, makes it convenient for end users to use their existing social accounts during login/registration. For more information refer Social Providers
Required Fields The fields defined in the Registration Setup are listed, and the Admin can select the fields that need to be made mandatory at the app level. For more information refer Registration Setup
Mobile Settings

When user login cidaas using the web browser in android Mobile phone, then it redirects to mobile apps.

How to get package name?

Package Name: Every Android app has a unique application ID that looks like a Java package name, such as com.example.myapp. This ID uniquely identifies your app on the device and in Google Play Store. If you want to upload a new version of your app, the application ID must be the same as the original APK—if you change the application ID, Google Play Store treats the APK as a completely different app. So once you publish your app, you should never change the application ID.

Your application ID is defined with the applicationId property in your module's build.gradle file, as shown here:

android {
    defaultConfig {
        applicationId ""
        minSdkVersion 15
        targetSdkVersion 24
        versionCode 1
        versionName "1.0"
How to get key hash?

Key Hash: Key Hash is used for authenticating the exchange of the information in between your application and your cidaas app or scocial apps such as (facebook ,google).

  • Open your Android Studio -> Create a new project -> Choose Blank Activity > Finish

  • Add the following Code inside the

package com.mytrendin.keyhash;

import android.os.Bundle;
import android.util.Base64;
import android.util.Log;


public class MainActivity extends AppCompatActivity {

    protected void onCreate(Bundle savedInstanceState) {

    public void printhashkey(){

        try {
            PackageInfo info = getPackageManager().getPackageInfo(
            for (Signature signature : info.signatures) {
                MessageDigest md = MessageDigest.getInstance("SHA");
                Log.d("KeyHash:", Base64.encodeToString(md.digest(), Base64.DEFAULT));
        } catch (PackageManager.NameNotFoundException e) {

        } catch (NoSuchAlgorithmException e) {



Copy the Key Hash and use it.

11.Enter package name and hash(#) key,

Push Configuration Secret:

An FireBase Push Notification Authentication Key for your Apple/Android Developer account. Firebase Cloud Messaging uses this token to send Push Notifications to the application identified by the App ID.

Note Go to here developer should register their app into firebase

13 . Click "Save" button, a message window pops up "Apps Saved Successfully".

Allowed Groups

App level access can be set by selecting appropriate roles and groups. For e.g. the App can be assigned roles such as SECONDARY_ADMIN, USER or GROUP_ADMIN, ect...

14 . Select appropriate roles from the drop down.

15 . Select appropriate cidaas Administrator roles from the drop down.

16 . Select appropriate groups from the drop down, as in the below screen,

17 . Click "Save" button, a message window pops up "Apps Saved Successfully".

Encryption Settings

Encryption settings provides data encryption function to secure data on mobile devices.

The JWE (JSON Web Encryption) specification standardizes the way to represent an encrypted content in a JSON-based data structure.

18 . Enable JWE and click “Save” button

Reference Link JWE

Json Web Tokens (JWT) are used to secure the information exchange between the users and the application. To provide more security to the access token the public and private key are defined.

Using a RSA asymmetric key pair, the JWT is signed with the private key and verified with the public key.

Public Key: key in PEM format, which is used to encrypt token content.

Private Key: key in PEM format, which is used to decode the encrypted token content.

19 . Once the appropriate App is created, the certificates (Public and Private keys) gets displayed as in the below screen.

App Custom Fields

User can define the custom fields (multiple fields can be defined). This is used for defining App level meta data for a business. For e.g. branch codes.

Flow Setting (Beta)

Administrators can configure the business flows at app level using the flow settings.It contains the following flow criteria:

  • Allow Login With: Administrators can specify the values with which a user can be allowed to login in this field (For e.g., username, mobile, email)

  • Register with Login Information: When the "Register with Login information" option is enabled, the user gets automatically registered when he opts for Social Login (Using Social providers such as Facebook/ Google etc.) on the Login page. If this option is disabled, when the user tries to login to the application for the first time before registration using Social login, an error message will be displayed. The user will have to then use social login on the registration page or register himself using classical registration.

  • FDS Enabled:: When Administrators enable this option, cidaas FDS detects if the user who tries to login is a legitimate user, based on pre-defined criteria.

  • Enable Passwordless Auth: Administrators can enable Passwordless authentication at App level

  • Enable Deduplication: Administrators can enable deduplication at App level. This option ensures that redundant users accounts are not created.

  • Allow Disposable Email: Administrators can allow user registration using disposable email (i.e. email IDs created by online fake email generators such as

  • Validate Phone Number: When Administrators enable this option, the user’s phone number is verified at the time of registration.

Note If the flow settings are not configured at App level, by default, the 'Tenant' level settings are applied.

20 . Click "Save" button, a message window pops up "Apps Saved Successfully".

21 . Once all the mandatory fields are filled, user get the Client ID and Client Secret, as in the below screen

22 . To reveal client secret id, click on the view icon .

23 . To reset client secret id, click on the reset icon , which provides a different client secret id.

24 . The created app gets displayed in “Your Apps”

25 . Cancel button redirects to app types screen.

26 . click the chart icon button that will shows the app usage chart it displays total number of login and registration, failure user’s counts for the particular date and time.

results matching ""

    No results matching ""