I want to follow along the Setting Up Auth0 tutorial in the Daml docs.
It is recommended that I deploy my Daml app and its JSON API on a remote server.
Does this mean that I absolutely cannot run this example application on my local machine?
Maybe Auth0 has some limitations which prevent this?
The instructions as written will not work on a local machine. The reason is a bit complicated, so let me walk through it.
For a production setup, you want your ledger to run in fully authorized mode. In particular, that means disabling implicit party allocation (or not enabling it, depending on your Daml driver and its defaults). Production ledgers (which is what we’re trying to emulate here) also don’t let you choose the entire party name, in general.
That means that parties have to be created before they can be used, and they’re unpredictable, which means someone has to create them. On the other hand, if you want people to log in through Auth0, they already have a preexisting “identity” (e.g. their email, or their login/password at the Auth0 level). So you need something, somewhere, to know the mapping between “external” identities (i.e. Auth0 “Users” you can find in your tenant dashboard) and Daml identities (i.e. party IDs).
That mapping has to be available to Auth0, because it’s the thing that knows the external identity and needs to create the token that contains the Daml identity.
The solution chosen in these instructions is to have Auth0 be the process that creates parties. That requires Auth0 to be able to reach the ledger (through the JSON API) to call the allocateParty endpoint. Auth0 can then store that mapping, and that allows it to produce the appropriate tokens for each user. In this approach, Auth0 is responsible for maintaining that mapping, and ensure that, on the one hand, a given external identity always gets the same party ID assigned, and, on the other hand, a single party ID is not assigned to multiple external identities. (Those are not strict Daml requirements and there are use-cases where you might want to break those constraints; the approach described on that page does respect them, though.)
This is the step that requires your JSON API to run on an IP address that Auth0 can reach, which is unlikely to be the case for your local machine (and would probably be a security issue if it were).
There are ways to work around that. One option is to preallocate parties, and Auth0 users. If you manually create an Auth0 user, you can also manually set its “app_metadata” and put a Party ID in there, as the Auth0 operator.
If you look at the getParty function in the Auth0 Action we configure, it first checks for a party field in app_metadata, and calls out to the JSON API to allocate a party if there isn’t one. You can change the logic of that function to suite more complex use-cases. In the preallocation case, you could simply abort if the app_metadata object does not have a party field, and rely purely on the operator setting those manually. That’s obviously less convenient for a real application, but would you let test the rest of the setup from your local machine.
Understood, thanks!