Application General Settings

A Single-Page Application (SPA) is a web application or website that interacts with the user by dynamically rewriting the current web page with new data from the web server, instead of the default method of a web browser loading entire new pages.

The goal of SPAs is to provide a more fluid user experience by performing most of the user interface logic in a web browser and communicating with the web server primarily using web APIs.

To create a single-page application on the cidaas admin dashboard, you need to navigate to Apps > App Settings, and follow these steps.


Scopes define the how the app will function and also lets the user define the different features.For more on scopes

Learn more about scopes here.

Hosted Pages

You can select a Hosted Pages group custom-created by you from the dropdown. By default, cidaas provides its own Hosted Pages for enterprise apps.

Redirect URLs

You can provide the Allowed Redirect URL for LOGIN which will be the default page where the user will visit after successful authentication when they log in. The Allowed Redirect URL for Logout can also be defined where the user will visit after successfully logging out from an app.

Learn more about Redirect URLs here.

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 the OAuth response types and origins.

1. Click Show Advanced Settings to view a similar screen

2. From the dropdown, select response types checkbox (multiple checkbox can be selected).

3. From the dropdown, select grant types checkbox (multiple checkbox can be selected).

4. Enter the allowed origins and allowed web origins.

Token Settings

1. From the dropdown, select Additional Access Token Fields checkbox (multiple checkbox can be selected).

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

You can upload or define your content 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 provided 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 users. To configure the consent for your user,

1. From the dropdown for Consent, select created consent group, as shown below:

Miscellaneous Settings

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

1. From the dropdown, select allowed providers checkbox (multiple checkbox can be selected).

2. From the dropdown, select required fields checkbox (multiple checkbox can be selected).

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

For more information refer Always ask for 2FA

4. Click Save.

Advanced Settings

Fields Description
OAuth Settings
Response Types The Response Type specifies the type of the response should be either code, token, or ID token.

The client constructs the request URI by adding the following parameters to the query component of the authorization endpoint


cidaas provides the following default Response Types, while creating the application:

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 application 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). cidaas provides the following default Grant Types, while creating the application: Implicit/ Authorization Code/ Password/ Refresh Token.
Implicit Grant: Implicit Flow is typically for a 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: It 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.
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 (the attribute entered for 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.

Allowed Groups

To configure this option:

1. Select the appropriate roles from the dropdown.

2. Select the appropriate cidaas Administrator role from the dropdown.

3. Select the appropriate groups from the dropdown, as shown below:

4. Click Save. A message window pop ups "Apps Saved Successfully".

Encryption Settings

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

Reference Link JWE

1. Enable JWE and click Save.


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.

Public Key: Which is in the form of encrypted.

Private Key: Which decode the encrypted token.

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

Application Custom Fields

A user can define the custom fields (multiple fields can be defined).

1. Click Save. A message window pop ups "Apps Saved Successfully".

2. Once all the mandatory fields are filled, the Client ID and Client Secret are displayed.

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

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

5. The created application gets displayed under Your Apps.

results matching ""

    No results matching ""