Powered by: altersoftware.IT
{{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.
La documentazione di {{label:productName}} è disponibile solo in inglese.
Cambi lingua (in alto a destra) per visualizzarla.
From user perspective:
Using the mobile app:
- Visits a web application that requires authentication, gets seamlessy redirected to fastauthentication.org (or another {{label:productName}} server): a QR-Code is displayed on screen
- Uses his “{{label:productName}}” mobile application to frame the QR-Code, and is back to the application - now authenticated.
Without the app:
- Visits a web application that requires authentication, gets seamlessy redirected to fastauthentication.org (or another {{label:productName}} server) and asks to be authenticated through email
- Receives an email with a link to be clicked for validation, and is back to the application - now authenticated.
Long story:
- The user approaches a web application that requires authentication.
- The web application asks {{label:productName}} to prepare an authentication session, and receives a URI for client.
- The web application redirects the user to the URI {{label:productName}} provided.
- The user sees QR-Code displayed on screen.
- The user uses his “{{label:productName}}” mobile application to frame the QR-Code, or asks to be authenticated through email.
- The {{label:productName}} mobile app sends the verification to the {{label:productName}} server, or the user clicks the link received in the mail.
- The {{label:productName}} server brings the user back to the web application, with an authentication token
- The web application server contacts {{label:productName}} to verify success/failure of the authentication token
- The user is back to the application, now authenticated
References:
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.