{{icon:status}} Docs

Single sign-on secure passwordless authentication system

{{label:productName}} is designed to perform a password-less authentication mechanism in a strong security context.

Authentication is performed using a mobile app reading a QR-Code on the screen, and will confirm the digital identity (a mail address) of the user.

{{label:productName}} is not a replacement for OAuth or similar processes, it simply grants user authentication: passwordless and securely.
It can be used as the authentication node for a single sign on multiapplication system.

Il sistema di autenticazione unica sicuro e senza password

La documentazione di {{label:productName}} è disponibile solo in inglese.

Cambi lingua (in alto a destra) per visualizzarla.

How it works

From user perspective:

Using the mobile app:

Without the app:

Long story:


{{label:productName}} key features

Of course the whole traffic occurs under HTTPS, but this is not enough.
{{label:productName}} is much more secure than this, and also in case HTTPS traffic is intercepted security will be granted in any case.

{{icon:locked}} User security and privacy

{{label:productName}} won’t ask for any password.

{{label:productName}} will never use users’ emails for any purpose different from authentication.

The user can decide which of the digital identities and/or associated informations belonging to him/her can be communicated to application servers.

{{label:productName}} will never communicate yor email address or other accounts to anyone, except for the required and allowed authentication purposes.

{{icon:mail}} {{icon:telegram}} {{icon:twitter}} Multiple authentication channels

User can login using existing mail and/or telegram and/or twitter account.

{{icon:notify}} Notifications

To increase security every user can set one or more digital identites to be notified on login and for alerts.

In this case in the event of a login, on in case of alert for profile change, the user is notified via Telegram and/or Email and/or Twitter, on which system, using which account (digital identity), from which IP address.

{{icon:mobile}} Secure and light client

Thanks to the booking mechanism the authentication process between client and authentication server will be quite light.
All the complementary informations necessary to the application server will travel directly from the authentication server to the application server, and this prevents forging.

At setup time the mobile application is provided with a unique, strong and very long passphrase, its authentication key.

The authentication process between client and authentication server only contains a variable fraction of the whole authentication key.
Also in case the HTTPS traffic is intercepted this doesn’t violate the security.

{{icon:telegram}} Easy and quick Telegram BOT

Contact @fastauth_bot and see how simple is to deal with it.

Using Telegram you can register, authenticate, list identities and manage their options, check if there are active authentication sessions and logout, and more.

Definition of authorized web applications

Only authorized and recognized web applications with their own public and private keys can use the {{label:productName}} authentication server, and start an authentication session for a client (see below).

Each customer can generate new public and private keys from Customer area.

Authentication sessions “booking”

An authentication process will take place only if requested by an authorized web application.

Only authorized applications can “book” an authentication session for a client, otherwise authentication attemps are simply dumped by HTTPD server.
This approach voids whatever brute-force attack.

An authorized applications books an authentication session, receives a token and a URL the client should be redirected to.
This starts an authentication session that lasts for 5 minutes.
The authentication process won’t start unless the client reports a valid token in its lifetime.

Multiple formats

The communications between both the application server and the client with the authentication server can happen using JSON as well as standard HTTP POST (UTF-8 encoded POST data).

Under no circumstances the user will be asked for any existing password.

Identities filter

Customers can optionally set a regular expression that digital identities must match.

This regular expression can be defined at both customer and booking level.

Custom identities — Customer specific private identities

Customers can associate to existing people their own custom digital identities.

Custom identities cannot be managed by users, and can be used only with the related customer.

Powered by: altersoftware.IT
Un servizio di: altersoftware.IT