Frequently Asked Questions (FAQs)

Frequently Asked Questions (FAQs) represent the list of questions and answers which are commonly asked in some context pertaining to topic.

How to integrate cidaas with my business check list ?

There are 3 main steps involved in integration of cidaas

  1. Admin Portal Login
  2. App Creation
  3. Generating Authz URL

1. Admin Portal Login :

Open the Admin portal and login with your credentials (which you have given using signup).

2. App Creation :

Once successfully logged in, go to Apps section in the Portal and create a new App.

The following things are to be kept in mind while creating an App

  • Select an App type. It may be either iOS, Android, Windows, Regular, Non-Interactive or Single Page application

  • Scopes have to be selected. Additional level of permissions or access rights can be defined for each App using scope parameter. cidaas ensures that the defined scope matches the actual scope allowed for the user and grants access to the user. (Some of the scopes includes “email”, “profile”, “openid”, “offline_access”, “phone”, “cidaas:register”).

  • Hosted page group has to be chosen (By default, “default” hosted group is added)

  • Redirect Urls and Logout Urls have to be added (Redirect URLs are the URLs to which the user is directed to after successful login. Logout URLs are the URLs which the user is directed to after successful logout)

  • Response Type has to be chosen. It may be either code, token or id_token

Code :

The authorization code flow is used by confidential and public clients to exchange an authorization code for an access token. After the user returns to the client via 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 only issued when the App has “openid” scope. The id_token issued is in the format of JWT token which is a compact, URL safe means of representing claims to be transferred between two parties. The claims in a JWT are enclosed as a JSON object that is used as a payload of a JSON Web Signature (JWS) structure or as the plain text of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a message.

  • Grant Type has to be selected. It may be either implicit, authorization_code, password, refresh_token or client_credentials. It is a good practice to choose “implicit” grant type for Single page web applications and “authorization_code” grant type for Native applications

  • Access token and Id token expires in” time has to be added

  • Required fields for the particular app can be chosen. If the fields are marked as required, then your customer will have to provide information for that particular field in order to successfully proceed with Login/Registration.

  • Allowed social and custom providers can be chosen

  • Enabling or Disabling Multifactor Settings. If you enable Multifactor Settings, it will ask 2 step verification every time, whenever your customer logs in through the App. For more information about MFA, refer

Roles can be chosen. By default, “USER” role will be added.

3. Generating Authz URL

Once App is created and listed (Client Id and Client Secret is shown), create login and registration for your customers.

For that you need to create an Authz URL. Please make sure, that all scopes, needed are requested within the Authz URL. An Authz URL requires redirect URL, viewtype and a response type. (All the parameters given in the Authz URL, must match the information given in the apps settings in cidaas, and are validated by cidaas in the request).

Authorization Code flow :

Authorization Code flow with openid scope : openid email phone offline_access&nonce=12345&redirect_uri=

If openid scope is added, then nonce parameter is mandatory. Nonce is an Opaque value, e.g. a random string, used to associate a client session with an ID Token, and to mitigate replay attacks. Use of this parameter is required in the implicit flow.

Change the response_type to token and id_token for other types.

Change the view_type parameter to register for Registration page

4. Token Introspection

Token Introspection is used to validate reference tokens. It requires authentication using a scope credential (only scopes that are contained in the access token can introspect the token).

Requests to the introspection endpoint must be either authenticated with client credentials or authorized with a bearer access token

For more information, refer

For implicit flow, token check happens on check session iframe

Check session :

After signing in a user with OpenID Connect the client application may need to periodically check if the user is still logged in with the openID provider.

For more information, refer

The process of integration, either native or with webview, is described exemplary with the Javascript SDK and iOS SDK below:

Integration with Javascript SDK (to illustrate Login UI/Webview integration)

Installation :
Initialization :
var options = {
    authority: “your cidaas base url”,
    client_id: “your client id”,
    redirect_uri: “your redirect url”,
    post_logout_redirect_uri: “your post logout url”,
    response_type: “id_token token”,
    scope : “openid email roles profile”,
    mode : “redirect”

If you want to perform silent login, add silent_redirect_uri and set mode as “silent”.

Instance Creation :

var cidaas = new CidaasSDK(options);

Login and Registration :
Login with Browser:


Handle login callback (access token, id_token, expires_in and other params) :

This will complete the login process by storing access_token, id_token, expires_in and other params in your browser session. If you forget to add this, login process will not be completed.

cidaas.loginCallback.then(function(response) {
    // your success code
    // Here you will get access_token, expires_at, id_token, scope, session_state, token_type and profile informations
}).catch(function(ex) {
    // your error code
    // Here you will get the error response such as any property or state missing
Registration :


Getting User Information :
cidaas.getUserInfo().then(function(response) {
    // your success code
// Here you will get access_token, expires_at, id_token, scope, session_state, token_type and profile informations

}).catch(function(ex) {
    // your error code
// Here you will get the error response such as any property or state missing
Logout :


For more information, refer

Integration with iOS SDK (to illustrate native integration)

Installation :

iOS SDK is available through Cocoapods. To install, simply add the following line in your Pod file.

pod ‘Cidaas’

Create a plist file named ‘Cidaas.plist’ and add the properties DomainURL, RedirectURL, ClientID

Instance Creation :

var cidaas = Cidaas.shared

Login and Registration :
Request ID :
cidaas.getRequestId() {
    switch $0 {
        case .success(let successResponse):
            // your success code
            // Here you will get request Id
            var requestId =
//Note*: This request ID is to be used in the Login and Registration code
        case .failure(let errorResponse):
            // your error code
            // Here you will get the error details
Login :
let login = LoginEntity()
login.username = “”
login.password = “xyzabcd”
login.username_type = “email” // by default “email will be taken”

loginEntity: login) {
//*Note: Used the requestID got from the getRequestId() mentioned above
    switch $0 {
        case .success(let successResponse):
            // your success code
            // Here you will get request Id
            var token =
        case .failure(let errorResponse):
            // your error code
            // Here you will get the error details
Registration :
let registration = RegistrationEntity() = “”
registration.given_name = “xxx”
registration.family_name = “yyy”
registration.password =123456”
registration.password_echo =123456”
registration.provider = “self” // either self or google or facebook or other login providers

cidaas.registerUser(requestId:45a921cf-ee26-46b0-9bf4-5863dced99”, registrationEntity: registration) {
//*Note: Used the requestID got from the getRequestId() mentioned above
    switch $0 {
        case .success(let successResponse):
            // your success code
            // Here you will get sub
            var sub =
        case .failure(let errorResponse):
            // your error code
            // Here you will get the error details
Getting User Information :
cidaas.getUserInfo(sub:5a921cf-ee26-46b0-9bf4-5863d”) {
    switch $0 {
        case .success(let successResponse):
            // your success code
            // Here you will get user information like email, given_name
            var email =
            var given_name =
        case .failure(let errorResponse):
            // your error code
            // Here you will get the error details

For more information, refer

Why do Modern Businesses need CIMS such as cidaas?

The customer is king. Never has the significance of this ancient wisdom been so great as today! Your customers are much more demanding and critical - thanks to the Internet and social media! With cidaas you can now know their expectations and manage them optimally.

Your customers want a comfortable and secure access to your portals, web shops or apps. With cidaas, customers can register and login using their own social media account. Easily and securely! That is cidaas provides the intelligent connect between User Convenience and IT-Security!

With cidaas...

  • you achieve reliable identification of your customers and their accounts across all channels.

  • you manage all your channels and services and replace your "Old Access Management" with ease.

  • you guide your customers through their customer journey and can personally delight them!

  • you benefit from transparent and predictable costs and a rapid implementation!

  • you can concentrate on your business - we take care of the necessary security and provide customer insights!

  • Get superlative returns on your investment: learn more about our current Pricing Plans.

How it Works?

cidaas is seamlessly integrated into your existing web-portal or across all your digital services, where your end-users need to register/login i.e. the user-interface will be designed as per your business specifications.

What is Redirect URL?

After a user successfully authorizes an application, the authorization server will redirect the user back to the application with either an authorization code or access token in the URL.

The best way to ensure the user will only be directed to appropriate locations is to require the developer to register one or more redirect URLs when they create the application. Native applications are clients installed on a device, such as a desktop application or native mobile application. The authorization endpoint normally redirects the user back to the client’s registered redirect URL.

You can specify multiple valid URLs by comma-separating them (typically to handle different environments like QA or testing). Make sure to specify the protocol, http:// or https://, otherwise the callback may fail in some cases.

What is Scope?

The scope parameter is used to indicate a list of permissions, that are requested by the client:

The authorization and token endpoints allow the client to specify the scope of the access request using the "scope" request parameter.

By adding scope, you can achieve more levels of security to the apps. You can add scope here (any string), cidaas then allows only the configured scopes while a user logs in. You can verify the access token, any time with cidaas, i.e. check if the access token has a scope.

A space-delimited list of scopes that identify the resources that your application could access on the user's behalf.

Scopes enable your application to only request access to the resources that it needs while also enabling users to control the amount of access that they grant to your application. Thus, there is an inverse relationship between the number of scopes requested and the likelihood of obtaining user consent.

OpenID Connect

OpenID Connect (OIDC) is an authentication protocol, based on the OAuth 2.0 family of specifications. It uses simple JSON Web Tokens (JWT), which you can obtain using flows conforming to the OAuth 2.0 specifications.

While OAuth 2.0 is about resource access and sharing, OIDC is all about user authentication. Its purpose is to give you one login for multiple sites. Each time you need to log in to a website using OIDC, you are redirected to your OpenID site where your login, and then taken back to the website.

For example, if you chose to sign in to cidaas using your Google account then you used OIDC. Once you successfully authenticate with Google and authorize cidaas to access your information, Google will send back to cidaas information about the user and the authentication performed. This information is returned in a JSON Web Tokens (JWT). You'll receive an Access Token and, if requested, an ID Token.

How the Protocol Works

Let's use the example we mentioned earlier, signing in to cidaas using your Google account, for a high-level overview on how the flow works:

1. When you choose to sign in to cidaas using your Google account, cidaas sends an Authorization Request to Google.

2. Google authenticates your credentials or asks you to login if you are not already signed in, and asks for your authorization (lists all the permissions that cidaas wants, for example read your email address, and asks you if you are ok with that).

3. Once you authenticate and authorize the sign in, Google sends an Access Token, and (if requested) an ID Token, back to cidaas.

4. cidaas can retrieve user information from the ID Token or use the Access Token to invoke a Google API.

Access Tokens: Access Tokens are credentials that can be used by an application to access an API. Access Tokens can be an opaque string, JWT, or non-JWT token. Its purpose is to inform the API that the bearer of this token has been authorized to access the API and perform specific actions (as specified by the scopes that have been granted).

ID Tokens: The ID Token is a JSON Web Token (JWT) that contains identity data. It is consumed by the application and used to get user information like the user's name, email, and so forth, typically used for UI display. ID Tokens conforms to an industry standard (IETF RFC 7519) and contain three parts: a header, a body and a signature.

Claims: JWT Tokens contain claims, which are statements (such as name or email address) about an entity (typically, the user) and additional metadata.

The OpenID Connect specification defines a set of standard claims. The set of standard claims include name, email, gender, birth date, and so on. However, if you want to capture information about a user and there currently isn't a standard claim that best reflects this piece of information.

OAuth 2 Flow

OAuth 2.0 is a protocol that allows a user to grant limited access to their resources on one site, to another site, without having to expose their credentials.


To get access to the protected resources OAuth 2.0 uses Access Tokens. An Access Token is a string representing the granted permissions.

Access Token Format:

  • By default, cidaas generates Access Tokens, JWTs contain three parts: a header, a payload, and a signature.

  • The header contains metadata about the type of token and the cryptographic algorithms used to secure its contents.

  • The payload contains a set of claims, which are statements about the permissions that should be allowed, and other information like the intended audience and the expiration time.

  • Signature is used to validate that the token is trustworthy and has not been tampered with.

OAuth Roles:

  • In any OAuth 2.0 flow we can identify the following roles:

  • Resource Owner: the entity that can grant access to a protected resource. Typically, this is the end-user.

  • Resource Server: the server hosting the protected resources. This is the API you want to access.

  • Client: the app requesting access to a protected resource on behalf of the Resource Owner.

  • Authorization Server: the server that authenticates the Resource Owner, and issues Access Tokens after getting proper authorization.

Protocol Flow: We will now have a more detailed look on how the protocol works. As we will see in a while, OAuth has many "flavors" (called authorization grant types) that you can use. For now, we will have a more generic consider the flow.

1. The Application (Client) asks for authorization from the Resource Owner to access the resources.

2. Provided that the Resource Owner authorizes this access, the Application receives an Authorization Grant. This is a credential representing the Resource Owner's authorization.

3. The Application requests an Access Token by authenticating with the Authorization Server and giving the Authorization Grant.

4. Provided that the Application is successfully authenticated and the Authorization Grant is valid, the Authorization Server issues an Access Token and sends it to the Application.

5. The Application requests access to the protected resource by the Resource Server, and authenticates by presenting the Access Token.

6. Provided that the Access Token is valid, the Resource Server serves the Application's request.

Authorization Grant Types:

The OAuth 2.0 Authorization Framework specification defines four flows to get an Access Token. These flows are called grant types. Deciding which one is suited for your case depends mostly on the type of your application.

  • Authorization Code: used by Web Apps executing on a server. This is also used by mobile apps, using the Proof Key for Code Exchange (PKCE) technique.

  • Implicit: used by JavaScript-centric apps (Single Page Applications) executing on the user's browser.

  • Resource Owner Password Credentials: used by trusted apps.

  • Client Credentials: used for server to-server communication.

What is JWE?

To generate the access token in the format of JWE.JSON Web Encryption (JWE) represents encrypted content using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification. Related digital signature and Message Authentication Code (MAC) capabilities are described in the separate JSON Web Signature (JWS) specification.

What is JWT?

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA. Let's explain some concepts of this definition further.

  • Compact: Because of its smaller size, JWTs can be sent through a URL, POST parameter, or inside an HTTP header. Additionally, the smaller size means transmission is fast.

  • Self-contained: The payload contains all the required information about the user, avoiding the need to query the database more than once.

Why a JSON Web Token is used for?

Here are some scenarios where JSON Web Tokens are useful:

  • Authentication: This is the most common scenario for using JWT. Once the user is logged in, each subsequent request will include the JWT, allowing the user to access routes, services, and resources that are permitted with that token. Single Sign On is a feature that widely uses JWT nowadays, because of its small overhead and its ability to be easily used across different domains.

  • Information Exchange: JSON Web Tokens are a good way of securely transmitting information between parties, because as they can be signed, for example using public/private key pairs, you can be sure that the senders are who they say they are. Additionally, as the signature is calculated using the header and the payload, you can also verify that the content hasn't been tampered with.

JSON Web Token Structure

JSON Web Tokens consist of three parts separated by dots (.), which are:

  • Header
  • Payload
  • Signature

Therefore, a JWT typically looks like the following.


Let's break down the different parts:

Header: The header typically consists of two parts: the type of the token, which is JWT, and the hashing algorithm being used, such as HMAC SHA256 or RSA.

Payload: The second part of the token is the payload, which contains the claims. Claims are statements about an entity (typically, the user) and additional metadata.

Signature: To create the signature part, you must take the encoded header, the encoded payload, a secret, the algorithm specified in the header, and sign that.

HMACSHA256(base64URLEncode(header) + "." + base64URLEncode(payload), secret)

The signature is used to verify that the sender of the JWT is who it says it is and to ensure that the message wasn't changed along the way.

To verify JWT (or manually create one), you can use the JWT Debugger.

How do JSON Web Tokens work?

In authentication, when the user successfully logs in using their credentials, a JSON Web Token will be returned and must be saved locally (typically in local storage, but cookies can be also used), instead of the traditional approach of creating a session in the server and returning a cookie. Whenever the user wants to access a protected route or resource, the user agent should send the JWT, typically in the Authorization header using the Bearer schema.

The content of the header should look like the following:

Authorization: Bearer

The following diagram shows this process:

What is Additional Access Token

The Access Token is a credential that can be used by an application to access an API.

It can be any type of token (such as an opaque string or a JWT) and is meant for an API. Its purpose is to inform the API that the bearer of this token has been authorized to access the API and perform specific actions (as specified by the scope that has been granted).

The Access Token should be used as a Bearer credential and transmitted in an HTTP Authorizationheader to the API.

How to get Access Token Payload?

1. From the created app, click “Edit” button

2. User can configure the additional payload to the access token,

3. This will be added to the app level settings

4. For example, take the below user information

5. User will get the final access token as in the below screen

6. Email: Email id of the user

7. Given Name: Name of the user

8. Family Name: Family name of the user

9. Mobile Number: Mobile number of the user

This is approval of user required to access the information of user. If this is enabled, window will pop up asking to allow or deny for accessing the information.

In order to enable the scope consent,

Navigate to cidaas Administrator dashboard -> Apps -> “Scope Management” and follow the below steps:

  1. Enter scope key.

  2. Select locale from the drop down.

  3. Enter a brief description about scope.

  4. Select security level from the drop down (public/ confidential).

  5. Select Scope Group from the drop down.

  6. Enable Required User Consent option.

Note: The consent page/form will appear only if the scope is enabled in the Update App Screen.

  1. Click “Save” button.

  2. The scope key is generated and gets displayed under “System Scopes” (System scopes are defined by the cidaas) / (custom scopes are defined by the user’s) section, as in the below screen:

Note: Administrator can enable user consent in both custom and system scopes.

After successfully enabling consent for a particular scope, the administrator has to ensure that the scopes are enabled in the corresponding app. If not enabled, follow the below steps.

Enabling the scope in the “App”:

cidaas Administrator dashboard -> Apps -> “App Settings”

  1. Select your business app from the below apps list and click on edit button.

  1. Go to app Settings section and update the scope (scope “profile” for example, as shown in the screenshot below) in the scope section and click save button.

  1. After the scopes are successfully added into the corresponding app, the user sees the corresponding consent form upon Login/Registration (on the cidaas authz login/register URLs) with proper scope. ex: “profile”

Login: https://samplecreative/user-profile/editprofile&view_type=login&response_type=token&scope=profile

Register https://samplecreative/user-profile/editprofile&view_type=register&response_type=token&scope=profile

When user clicks on accept button, that time you allow this app to use your above-mentioned scope ex: (profile) claims information such as (name, family_name, given_name, etc…) in accordance with their respective terms of services and privacy policy.

What is Mode?

Through mode user can specify which type of redirection needed. (i.e. window, redirect or fancy box deprecated).

results matching ""

    No results matching ""