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.
Why do Modern Businesses need a Customer Identity Management Solution 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!
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 (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 Token (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 into 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.
The signature is used to validate that the token is trustworthy and has not been tampered with.
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.
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:
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.
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:
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 get the final access token as in the below screen
6. Email: Email id of the user 7. Given Name: Given name of the user 8. Family Name: Family name of the user 9. Mobile Number: Mobile number of the user
Enable User Consent
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.
What is Mode?
Through mode user can specify which type of redirection needed. (i.e. window, redirect or fancy box deprecated).