Hi there, I might be missing something, but the login workflow is kinda particular . Why donât you use directly sign in wih apple instead of â convert regular login password to registered biometric workflow that still generates a passwordâ ?
plus having access to the password is a big red flag in gdpr world.
Hello, sign in with Apple is not a broswer api, it requires the developer to make a call to Apple server after registering their application for oauth.
This plugin does not generate a password, it returns a credential id via javascript promises, as outlined on the plugin page.
We included two extra actions to encrypt and decrypt the password using salt (the same technology Bubble uses). So the developer does not have direct access to the password stored in the database.
I dont understand your first question, could you rephrase it please? Yes itâs the same process described by Webkit.
If you are concerned about storing passwords, an option is to use âgenerate temporary password actionâ. This will circumvent the need to do any encryption, although it resets the users password each time.
Then when your user would like to sign without Face/Touch ID, you would send them an email with a special magic link containing a secret parameter. On page load, cross reference the secret and log the user in accordingly. This flow is similar to Bubbleâs native password reset.