Get tokens for users who don't exist

Hi all.

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.

Edit: Doing some research and I think what I am looking for is something like: Autenticação anônima com o Firebase usando JavaScript

Dom

1 Like

Hi Dom,

Quick answer: yes I think this is doable, but it is fairly complex. This is one I would recommend Auth0 professional services for guidance:

It is not just a question of making a solution that solves the technical issues, but also doing so in a secure fashion. That makes this complex.

John

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.

1 Like

Thanks so much for exploring this with me.

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?
  • Store token on local storage?

Thoughts?

Understand its an old post, did you get a solution to this @Dominic_Bou-Samra ?