Is it secure? Using rule context to add external service access token

Help
,
1

Hey folks, I need to attach to my user’s info/context an extra connection token to access an external service, in this case, FaunaDB. So, I think Auth0 rules are great for this purpose but I don’t know how safely it is. Here is a code sample on how I’m thinking to do that:

async function (user, context, callback) {
  try {
    const token = await createFaunaDBToken()

    context.idToken['https://db.fauna.com/secret'] = token.secret;

    callback(null, user, context);
  } catch(error) {
    callback(error, user, context);
  }
}

Is this safe? If it is not, how should I do to attach a token to the user?

Thanks!

1 Like
2

Short answer: I don’t know. This sounds fairly complex from a security perspective, so I cannot comment.

But I did notice you are putting the extra token in the ID token. I think that should be in the access token. But again, I cannot comment on the security of this - it really needs a security review

John

2 Likes
3

Do you know what are the diffs between use ID Tokens or Access Tokens from a rule? Do you know someone can help us to solve that questions?

4

HI @BrunoQuaresma,

can you give a bit more information about your setup. What OAuth2 flow are you using, what type of application is it on your end? A SPA (Single Page Application) without backend, or a backend with it? Stateless or stateful client?

to access an external service, in this case, FaunaDB

Also, from where would this connection be established from? Your frontend or your backend?

General difference between ID and Access Tokens: Tokens
The way they’re accessed in a Rule though and how custom claims get access is the same.

2 Likes
5

Hey Mathias,

Currently I’m not using a specific OAuth flow. I just have a SPA(a react app) that connects directly to the FaunaDB(FaunaDB has their own authN and authZ system). Initially, I would like to use Auth0 to sign up/in my users using the email/password provider and after, add other providers like Facebook, Google, etc.

What I’m trying to do is sync the user base on Auth0 with the one in FaunaDB. So I can generate faunadb tokens for these users. What I currently have is:

  • A hook for the sign up to save the users on faunadb as well.
  • A rule to attach the faunadb token(this token can be used to query the user data in the database.) related to that user on the sign in context .

My main question is on the last one. I would like to check if passing this info on context is secure enough for this scenario.

Thanks!

6

@mathiasconradt thoughts?

7

Did you come up with a solution, I’ve been thinking about the same I have a Gatsby app connected to auth0 and I’m planing on making a hook on sign up so it would update in my faunadb database I wanna go serverless

8

Hey Gabo, many users take this approach. It’s fair that Auth0 can’t answer whether this approach is secure since it involves a synchronization with FaunaDB that involves FaunaDB tokens/keys which they can’t really judge on.

Hence, I’m going to try and help. The part that actually matters is whether it’s safe to place a powerful FaunaDB key (one that can create users and optionally tokens) in an Auth0 rule. We can assume that that is safe since those are executed on a secure environment provided by Auth0.

Users/writers (e.g. From Static Sites To End User Jamstack Apps With FaunaDB — Smashing Magazine) are in each case using rules to sync FaunaDB users with Auth0 users. That’s fine but a bit cumbersome, especially in case you want to delete users later on.

In this particular case, he is indeed using the ID token as a way to send a FaunaDB secret to the frontend. Many companies have different opinions on how to use ID tokens/self-contained access token and it is often frowned upon but I’m not here to express an opinion about that. Since you are sending that ID token over https and since that secret will be anyway used by your frontend I do think security-wise this is just as secure as placing a secret in the frontend in any other way (but I’m not a security expert).

The other and better way would be to have a partial backend to handle that flow and/or only place the email of the user (if it’s not already) on that ID token and create the FaunaDB token in the backend by validating a token (ID or access, typically if it’s for the backend I think Auth0 recommends using an access token but correct me if I’m wrong @mathiasconradt ), looking up that user via the email and creating a token for it. Which you can easily do in a serverless function. If you then choose to access FaunaDB from the frontend (you can do so if you apply the right security roles) you can still forward that Fauna token to the frontend and you gain the advantage that you could store information to refresh the user in a httpOnly cookie.

We are currently implementing examples and aim to release features that allows easier integration with an identity provider like Auth0. I know that this answer leaves a lot of gaps but I did want to give you some sort of answer in the meantime.

3 Likes
9

Thanks for providing that insight @fauna-brecht!

1 Like
10

Hey there!

As this topic is related to Rules - Hooks - Actions and Rules & Hooks are being deprecated soon I’m excited to let you know about our next Ask me Anything session in the Forum on Thursday, January 18 with the Rules, Hooks and Actions team on Rules & Hooks and why Actions matter! Submit your questions in the thread above and our esteemed product experts will provide written answers on January 18. Find out more about Rules & Hooks and why Actions matter! Can’t wait to see you there!

Learn more here!