This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
Desktop Flows
Anonymous
- If no auth_token is present,
internal-api/user/newis called bylbryinc.Lbryio.authenticate - An auth_token is returned, which looks like this:
738oP8hAK71Qfexd3urfd9nyCyxPkgoG response.auth_tokenis kept and sent with all subsequent requests as a POST queryauth_tokenparameter
Registration
internal-api/user_email/newmethod is called with user’s email as an argument- An email with a confirmation link is sent to the user
- Desktop starts querying
internal-api/user_email/status - User clicks the link in the confirmation email, calling
internal-api/user_email/confirm
Passwordless Authentication (with Merging)
The passwordless authentication allows users to "login" without concern for a password. In this system the ownership of an email account replaces the password for an account. This is more secure than a password because even with a password an account can in almost all cases be reset with access to the email associated with the account.
LBRY has implemented a passwordless system that creates an auth_token for each user when an account is registered as described above.
The login process starts from a state where the user is not logged in. This is described in the anonymous section above. From this point the user logs in by providing their email address. This triggers a call to the internal-api/user_email/new api. Inside the call we check if the email exists already or not. If it does and belongs to a different account, a verification token is generated and sent to the email address as a link to click. The user has 15 minutes to click the link to prove ownership of the email. This is done by passing back the sent verification token to internal-api/user_email/confirm via the link provided in the email.
Once ownership is confirmed we now know that the anonymous user and the user associated with the email are the same person. At this point internal-apis merges the two users into one. This is a complex transaction in the database:
https://github.com/lbryio/sqlboiler/blob/master/templates/singleton/boil_queries.tpl#L23
There are some pre-merge cleanup operations performed here:
Authentication
- On every api call that requires authentication, the
auth_tokenthat is sent with api call is used to validate permissions and constraints based on scope. Theauth_tokenis grabbed from the db and its scope is checked. These scopes dictate permissions and constraints. If the token is a scoped token (i.iscopeis notall) then requirements of the api are validated against the permissions and constraints approved for that scope. If not approved an authentication error is returned.
LBRYweb Flows v0.1
Anonymous
- If no session is present, internal-api’s
internal-api/user/newis called - Lbryweb forwards the call to internal-apis and returns back the full API response, saving
auth_tokenfor the current client session
Registration
- UI submits user credentials (email/password) to lbryweb
- lbryweb calls
internal-api/user_2fa/newwith user’s email and password - internal-apis send the confirmation email, including a link to the lbryweb confirmation address instead of lbry.com.
- UI starts querying
internal-api/user_email/status - User clicks the link in the confirmation email, calling
lbryweb/confirm, which forwards the data tointernal-api/user_email/confirmand marks user as registered in the lbryweb database in case of a successful response
Authentication
- UI submits user credentials (email/password) to
lbryweb/user/auth. - lbryweb calls
internal-api/user_2fa/newproviding user credentials. - In case of successful password authentication, UI starts querying
internal-apis/user_email/statusand an email sent with a link to lbryweb. - User clicks the link in the confirmation email, calling
lbryweb/user/2fa_auth, which forwards the data tointernal-apis/user_email/confirmand marks user as authenticated in the lbryweb database in case of a successful response.
Lbryweb/Internal-API Authentication Workflow
- Certain APIs will be protected by 2FA. For example wallet apis. A new global parameter for the password will be passed via the respective apis. If these APIs have a 2FA constraint, then it will need to pass the constraint. This constraint requires the primary email to be verified as well as the password to be authenticated.
List of internal-api endpoints to be implemented
internal-api/user_2fa/new
Open Questions
- What do we do about the password resets? This could be solved with the signal SDK which allows for asynchronous key exchange. Since we are dealing with wallet data we want any password reset to be secure. The device which creates the password should create a key pair and pass the public key along with the password which internal-apis stores on init. This public key proves we are talking with with the device we created the password on. It also allows us to accept a signed password reset request without relying solely on email. This private key can be asynchronously exchanged with the other devices so the password reset can come from any registered device.
LBRYTV Flows v0.2
Anonymous
- If no session is present UI calls
internal-api/user/newandauth_tokenis retrieved - UI forwards
auth_tokento lbryweb, a user record is created and an account is registered with the SDK
Registration
internal-api/user_email/newmethod is called with user’s email as an argument- An email with a confirmation link is sent to the user
- UI starts querying
internal-api/user_email/status - User clicks the link in the confirmation email, calling
internal-api/user_email/confirm - UI sends
auth_tokento lbryweb, a user is marked as registered