User-Centric Privacy
No Personal Data, Consent Required
This section still requires as an update as we now do offer the possibility to store customer data in Quasr.
Personal Data
Quasr is designed to not need and even avoid using customer data, which is your users' (personal) data, as we believe authentication can and should not utilize any customer data. This allows you to keep customer data secure and compliant in a suitable market solution of your choice, while it also benefits the customer (= your user) from a trust and experience perspective. Hence most solutions with Quasr will need to be paired with some suitable and privacy-friendly 'Customer Data Solution'. Let's dive into some examples to better understand what we mean.
Username
Lots of solutions set requirements on the username and keep this in clear, for example demanding use of an email, and using this for certain functionality. This is often not desired from a customer's point of view (= both you and your users), as you may not want this data to be stored / processed by your authentication solution and the end-user might not prefer using an email.
Hence Quasr does not set any requirements on usernames and all usernames are securely hashed within the Quasr platform. This means no restrictions on what you can use as username but also if you need the email it won't be possible to get this out of Quasr. This is where your Customer Data Solution will need to play its part.
Say you want users to use their email you can request / enforce this in your UI — or create a new username factor with a restricting regex. When they sign up you'll send the email as username to Quasr, which gets hashed and you receive a unique account ID in the API response. It's important to link the Quasr account ID to the account you'll keep in your Customer Data Solution. The latter also being the place where you could store the email in clear for your own use.
One-Time Password (OTP)
You may now wonder so how does Quasr deliver one-time passcodes (OTPs) to customers in case it doesn't have relevant data like the email. Well the solution is simple, when Quasr wants to deliver an OTP to your user it will call an extension. This extension is to be configured by you and points to an API on your end. This API will receive the Quasr account ID as well as the OTP and some useful info you could use to communicate to your user. Your code will use the Quasr account ID to retrieve any required personal data from your Customer Data Solution and next it will deliver the OTP to the end user (through any communication channel you choose).
This extension (webhook) approach is already popular in the industry as it allows you to plug in any channel for your users. Often customers reuse an existing email or SMS gateway, but the approach also gives flexibility in integrating whatever communication channel your users prefer.
Tokens
Next you may wonder how to get customer data into the tokens Quasr issues to your applications. Again the solution lies in some extension. Quasr offers the option to run custom code to inject any relevant data in its tokens. One of the parameters this piece of code receives is the Quasr account ID for the user for which tokens are to be issued. In this code you can call an API on your end which takes in the Quasr account ID, retrieves relevant data from your Customer Data Solution, and sends data back to Quasr to be added to the tokens.
If you send customer data in clear it will get processed in clear in the Quasr platform, but it won't be stored or captured say in logs. The processing is minimal as your custom code will provide custom claims, which immediately go into the next step where the tokens are forged and returned to your application.
Consent Management
If authentication solutions offer consent it often is built in as an afterthought or through integration with a 3rd party. At Quasr we feel consent shouldn't be an afterthought or a third party feature but actually plays a vital role in any privacy-minded authentication platform. Hence Quasr provides and requires consent as part of its main authentication flows. A usual flow looks like this:
User accesses application and is redirect to the authorization server (Quasr)
Authorization server redirects to login UI (customer) which uses the Quasr APIs
Upon successful login or sign-up the login UI must seek consent to obtain a consent token.
Login UI redirect back to the authorization server with the consent token.
Authorization server redirect back to the application with requested tokens.
Quasr currently offers consent options for API access (OAuth 2.0 scopes) and legal acceptance of statements or documents. Additionally it provides the option to time-box a consent which will also time-box any related access.
The login UI is considered a trusted client meaning that whatever it communicates to the APIs is considered to be aligned with system and customer expectations. Say a user does not consent, the login UI must respect this and not indicate the opposite to the Quasr API.
Last updated
