The Webcom Authentication Service makes it possible to reliably identify users of Webcom applications, in order to finely control their access to data. It additionally retrieves user identity details when they sign in, which can be used by applications to customize their behavior (user experience, specific configuration...).
Four classes of authentication methods are currently available to identify users:
- Guest login, which associates a temporary (virtual) user account with a device connecting to a Webcom application,
- Own authentication methods, based on identities directly managed by the Webcom
back end. Among them, we find:
- Email-based login, based on the user email address and a password set by the user,
- Phone-based login, based on the user phone number (MSISDN) and a one time password sent to the user by SMS,
- Delegated authentication methods, based on a 3rd-party identity provider. Among them, we find:
- Implicit login of Orange mobile devices, based on the Orange mobile data network, and the SIM card of the device,
- Standard authentication delegation based on the
OAuth2.0 standard for authorisation.
It includes in particular OIDC, Mobile Connect, and Orange Connect for Orange employee authentication, - Custom authentication delegation for platforms that have a specific authentication mechanism,
- Server login, dedicated to machine-to-machine authentication and based on JWT tokens.
Each method returns:
- a Webcom account (or uid), which is a user identifier unique across all authentication methods for a given
application.
As it is guaranteed to be unique, this identifier should be used by applications to associate some data to their users. - an identity (or providerUid), which is a user identifier specific to each authentication method.
Conversely, as this identifier cannot be guaranteed to be unique across the various authentication methods, it is strongly discouraged to use it to refer to a user within an application.
The Webcom authentication model makes it possible to bind several identities (providerUid) of the same user to the same Webcom account (uid). This brings two main advantages to Webcom applications:
- an end user is not constrained to always use the same authentication method. For example, s/he can sign in using either her/his email (with the email-based login) or her/his facebook account (with the corresponding standard authentication delegation method).
- an application may require several authentication methods to access some sensible data. For example, the user may
be forced to sign in using an SMS one time password in addition to her/his initial email-based sign in before reading
the amount of her/his bank account.
This is the way Webcom implements multi-factor authentication.
- The Webcom Authentication Service may also be used “standalone”, without any dependency to other Webcom services such as the Datasync Service.
- When using a Webcom own authentication method, users must be signed up before being allowed to sign in (don't laugh, it's really the first source of failure! 😉).