looking for an advice how to properly integrate Custom Database and Passwordless (magic-links) approach on Auth0.
We're using Custom Database integrated with PostgreSQL, but our users asking for "magic links" approach (as on Slack auth flow).
According to Auth0's documentation, Custom Database and Passwordless are different "databases of users", and can't be integrated between.
Does anyone had any approach to generate magic-links to authenticate users automatically from Custom Database?
Thanks in advance!
I wanted to reach out and confirm that there is no out of the box solution for allowing Custom Databases and Passwordless integrate with one another. I hope this helps confirm your findings as you continue on with your quest. Thanks!
You would need to a Passwordless connection in Auth0 (Passwordless Email because Passwordless email would not save the user's email) and then add Account Linking Rule which will detect verified accounts with the same Email and merge them into one, with possibly the Custom DB account as primary account and Passwordless email account as secondary. The user can choose to log in using eighter option.
The account linking rule is highly customizable too and you can even roll out your own Account linking logic using Management API which allows for Linking/Unlinking accounts: https://auth0.com/docs/api/management/v2#!/Users/post_identities
Related
I was wondering if it was possible to login to different salesforce environments (Sandboxes, scratch orgs, production env, etc) using either Apex/LWC/Aura (or anything that I can make a quick action to). For example, I have a list of credential records, with the username and password, and I would like to have a login button that creates a separate tab that can automatically redirect to that specific instance and log in.
Currently, if a user wants to login to a particular instance, they have to either go to test.salesforce.com or login.salesforce.com (depending on if it's a sandbox or production) manually, then copy the password and username in. The ideal situation is to have a login button that can do this automatically from the record page where the username and password is located.
I think previously this could have been accomplished through the URL, but salesforce has recently patched this out due to security concerns. Is there another good way to do this?
It sounds like you're trying to solve two specific challenges:
Your users need to be able to manage very high volume of credentials.
You need authentication to survive password resets.
The clear solution, in my mind, is to use the OAuth Web Server flow to execute initial authentication and then store the refresh token that results from this flow. This token survives password resets, and may be used more or less indefinitely to create new access tokens - which users can then use to log in via a frontdoor link.
There's an out-of-the-box tool that does this already: the Salesforce CLI. You can authenticate orgs to its toolchain, name them, and subsequently access them with a single command (sfdx force:org:open). Users that prefer a GUI can access the exact same functions in Visual Studio Code.
If you're hellbent on doing custom development to handle this use case, you can, but you need to be very careful of the security implications. As one example, you could implement an LWC + Apex solution that executed the relevant OAuth flows against orgs and stored the resulting data in an sObject, then allowing users to click a button to generate a new access token and do a one-click login.
But... if you do this, you're storing highly sensitive credentials in an sObject, which can be accessed by your system administrators and potentially other users who have relevant permissions. That data could be exfiltrated from your Salesforce instance by an attacker and misused. There's all kinds of risks involved in storing that kind of credential, especially if any of them unlock orgs that contain PII or customer data.
One of the two best answers for that (the other one being 'pure Apex' and relatively more complex) is using Flow.
"You can use a login flow to customize the login experience and integrate business processes with Salesforce authentication. Common use cases include collecting and updating user data at login, configuring multi-factor authentication, or integrating third-party strong authentication methods.enter image description here"
"You can use login flows to interact with external third-party authentication providers by using an API.
For example, Yubico offers strong authentication using a physical security key called a YubiKey. Yubico also provides an example Apex library and login flow on GitHub. The library supplies Apex classes for validating YubiKey one-time passwords (OTPs). The classes allow Salesforce users to use a YubiKey as a second authentication factor at login. For more information, see yubikey-salesforce-client.
You can also implement a third-party SMS or voice delivery service, like Twilio or TeleSign, to implement an SMS-based multi-factor authentication and identity verification flow. For more information, see Deploy Third-Party SMS-Based Multi-Factor Authentication."
learn more here: enter link description here
I am currently using Auth0 to allow users to log in to an application. I am building it using the embedded approach. I see in the Auth0 documentation that they support passwordless login for SMS and email but I am not sure if that is the correct approach to use for a one time code when a user forgets their password?
Has anyone developed a forgot password and reset through embedded with Auth0? What approach did you use? Is passwordless strictly for logging in?
Important - this is not the universal login approach.
Thanks.
There are multiple ways in Auth0 that user can be authenticated. Those are categorized under the Connections in Auth0. Passwordless is one way of doing so. In this approach there is no password involved in. Which means, there can’t be a use-case, where the user forget his password for your application. (What can happen is that user forget his password for his email account or user would no longer have access to mobile phone, where he receive the SMS from Auth0 for authentication.) So passwordless is not for reset user password. It is just for Authenticate the user.
If you provide an option to login with Username and Password you can use Database connection type in Auth0. In this approach, there is a use-case where, user forget his password for your app.
In that case your application should provide the forget password option. In Universal Login, it has built in support for this. However, as you don’t use Universal Login, you may have to implement that by yourself.There are couple of methods which are explained in Auth0 Documentation. One options would be to use change_password endpoint in Authentication APIs. This will send an reset password email to user. Then user can use the link given in that email to reset his password. There is another option, where you can generate a password reset ticket in Auth0 using the password reset ticket endpoint. Hope you can use one of them for your requirement.
I'm trying to figure out which OAuth2 grant to use for my application/saas. Or if OAuth2 is even the correct way to go.
The application:
The purpose of the application is for use and integration with e-commerce. So what I want is for the user is to go to my site and register an account. After the account has been created the user should be provided with credentials with which he/she can acquire an access- and refresh-token. The access-token should provide access to the users OWN resources and preferably use scopes to limit access. The user should the be able to get/post/put and delete stuff from his/her account as if working in the provided administration (SPA).
They should not have to go through the OAuth redirect flow, because they will be using the API from their servers.
My thoughts
First I considered going for the Client Credentials grant. But then I found out that it will not provide access to a user and it's resources.
I've started leaning towards using the Resource owner credentials grant. But I don't put a lot of faith in my users picking strong passwords. And in almost all documentation I can find, everyone seems to not recommend using this grant.
Maybe OAuth is not suitable for my project? Maybe I should go for some API Key which can be traded for an access token?
Any thoughts and/or input?
I've one link which may useful for you.
Link: https://github.com/lucadegasperi/oauth2-server-laravel/blob/master/docs/authorization-server/choosing-grant.md
Came to the conclusion that OAuth2 was not correct for my situation.
In the end I chose to go with a custom solution based on JWT.
I am provisioning accounts on my domain with the Directory API.
Right after I create the user, I want to subscribe them to a bunch of calendars as part of their account setup.
Previously, I did this with ClientLogin by authorizing as the newly-created-user (because I knew the password). But ClientLogin has be deprecated.
Is there another way of achieving this?
To answer my own question:
You can do this by using service accounts to authenticate and act on behalf of the user without the user's knowledge.
https://developers.google.com/accounts/docs/OAuth2ServiceAccount
I'm developing an application where Google Drive will be used to manage some documents. The idea is to create a document with some initial template data and provide the users access by adding them as collaborators of the document.
I'm familiar with the OAuth authentication process, I used it in another part of the system to manage the users Calendar...
But in this case these documents will be stored in a generic account of the company, so I can't have the approval prompt for authentication, since users won't have the password of the account.
I'd like to directly authenticate in this account, could be with the username and password hardcoded in the Java code.
Problem that this method of authentication was depreacated and I didn't found a relpacement.
Any ideas?
Thanks in advance,
Phillip
There are 2 ways that comes to mind:
Service accounts: best suited for server side OAuth with traditional backend
Regular Account owned by the application : similar to the process already in place for client side Oauth that you are already familiar with; Auth, store the refresh, ask new token if the AuthCode is expired, and so on.
I personally use and prefer the second solution more as I feel is more flexible to adapt in the future for Oauth Client Side get the tokens and use them server side.