About to start implementing a new feature whereby owners/managers of a resource, can enter a list of emails, and share that resource with them. These emails aren’t in our system at all, they are considered guest viewers of this resource (medical images in this case). They will have limited permissions, and only on that specific resource.
Does anyone have any suggestions or ideas that jump to mind?
Is any of Auth0’s Passwordless stuff useful here? I haven’t thought too far ahead, but maybe we email them a link, and when they open that link, it prompts them to enter their email. This then creates some sort of anonymous user within Auth0 with limited scope. I should say I require a token with certain scopes in order to use our API.
Are you able to provide a brief overview of the approach? I don’t necessarily want to engage professional services at this stage: it’s still a side project right now.
Is there a risk that users reshare links? In other words: do you need that specific user authentication, or would just a cryptic link (like Google Drive, Dropbox, Nextcloud, etc. does it) does it work general shareable links as well? (In the way that everybody who gets hold of the link would have access).
I believe, since it’s medical images, it’s critical data and you want this additional authentication layer in between, but just confirming, because this simple ‘cryptic’ link approach would of course be pretty easy to implement (without Auth0 even involved). Just checking that this is an option you’ve considered and already ruled out.
Is there a risk that users reshare links? In other words: do you need that specific user authentication, or would just a cryptic link (like Google Drive, Dropbox, Nextcloud, etc. does it) does it work general shareable links as well? (In the way that everybody who gets hold of the link would have access).
I think the cryptic approach is fine for now. Let’s explore this approach for now. What would it involve?
I think the cryptic approach is fine for now. Let’s explore this approach for now. What would it involve?
Simply generate this random string, store it in a way in your backend linked to your document(s), then share it with the user in some way (i.e. email). As you can see in the example, it’s a generic path, where the backend then figured out based on the random string / stored mapping, which document to show.2
In this scenario, there’s no involvement of the Auth0 platform needed.
So this was the approach I initially considered. However, this won’t work without huge modification to our backend. We currently require a token when accessing the API. Ideally this token will come with limited scopes, and we can control auth easily that way.
Could we perhaps have a “sharing@company.com” user, and issue tokens from this fake user to the client from our backend server using the approach you described above? So the flow might look like this:
User X shares resource A to User Y
Backend processes share request and:
Creates entry in backend DB with the resource ID, who it’s shared to etc.
Get an access token for that fake user, with permissions set to something like “read:resource:A”
Send share email with access token embedded in query string to User Y’s email.
User Y opens email, access token set in localStorage and proceeds.
Is that completely dodgy to:
Send a token from the server in an email like that?
