This article provides an overview of the authentication mechanisms available in Cloud Identity Plane.
Authentication is the process by which clients of CIP (for example, users or applications) provide credentials to prove their identities. The CIP authentication service exposes a variety of authentication schemes, which support use cases for different types of entities. In most cases, a successful authentication is followed by the creation of a new user session (represented as a session token) or with additional authentication events to a current session (resulting in a session upgrade).
Each authentication endpoint accepts a device print so that the user device can be recognized and assigned to the user for a future use in authentication and authorization policies.
For each successful authentication and verification and each unsuccessful verification request, an event is emitted. Services, such as the CIP risk service, listen to those events and use them, for example, for building their session/user/IP/application knowledge base to calculate risk for those entities.
CIP supports a number of authentication methods as explained below.
ID + password authentication
Authentication with a user’s identifier (ID) and password is the most basic form of authentication that CIP provides. The concept of identifier is flexible and by default means any self-signed identifier (UID), verified mail, or verified mobile.
When a user is created, his/her password is specified along with the user identifier. In some flows, the user password is not specified until the user is activated.
ID + password verification
This endpoint exposes the same logic as its authentication version but does not issue a session. It can be used for an additional password verification for actions that require an extended authorization. It is mostly used internally by other microservices.
ID + TOTP authentication
Another form of authentication that CIP provides is the authentication with a user’s identifier (ID) and time-based one-time password (TOTP). There are multiple types of authenticators for TOTP. CIP TOTP implementation works with well-known authenticator apps such as Google Authenticator, Microsoft Authenticator, and more.
For more information on the TOTP authentication, see RFC 6238.
The user can provide the password and the session token to prove the password knowledge. The session needs to be valid and the password needs to belong to the user for whom the session is issued.
The user can provide the valid TOTP code and the session token to prove the ownership of the device with configured TOTP for that user. The session needs be valid and the TOTP code needs to be generated for the user for whom the session is generated.
For more information on the TOTP verification, see RFC 6238.
The user can provide the valid OTP code and the session token to prove the access to either an email address or a mobile number. To get the OTP code, at first the user needs to request it using the session token and choose one of the unverified or verified mails or mobiles. The session needs to be valid and the OTP code needs to be sent to the user for whom the session is generated.
The user can provide the response to previously-requested knowledge-based answers (KBA) questions and the session token to prove the KBA knowledge. First, the user needs to request a challenge and the system decides which questions the user needs to answer to pass the verification.
Once the user gets the challenge and answers the questions, the system verifies if the answers match (case-insensitive) those used during the KBA setup. The session needs to be valid and the KBA responses need to match the answers of the user for whom the session is generated.
SFA vs MFA
Basic single-factor authentication (SFA) flows that can be used to obtain a user session in CIP are
- Identifier + password authentication
- Identifier + password verification
- Identifier + TOTP authentication.
The user’s session can be subject to additional authentication flows exposed by the CIP authentication service to increase identity assurance. Most of those extended authentication verifications are requested by an authorization policy engine in the CIP authorization service. Those flows may act as second-factor authentication (2FA) methods if a fully-authentication policy is configured to require not only a valid session but also an additional verification.
The CIP multi-factor authentication (MFA) solution links security policies when MFA (extended authentication) is required for specific transactions. It reduces the frustration of users faced with excessive multi-factor roadblocks for low-value transactions while providing the needed level of identity verification for high-value transactions. The MFA service supports SMS, verified email, and voice communication channels.
The MFA service includes several methods of authentication:
- Password verification
- Time-based one-time password (TOTP)
- One-time password (OTP), delivered via email, SMS, or voice
- Knowledge-based authentication (KBA).
External MFA providers
CIP supports external MFA providers (for example DUO). The capability to integrate external MFA providers allows flexibility to add any custom supplier.
DUO is a multi-factor authentication method offered through DUO Security. Contact a system administrator if you are interested in enabling DUO for your organization.
For more information on DUO, see Multi-Factor Authentication from Duo.