Managing an open source project which uses Auth0

[brettski]

We have developed an open source Nextjs application using Auth0 to handle our authentication. We have others in our community who would like to contribute, though we are not exactly sure how to handle to Auth0 side of things. Obviously we can’t provide them with our keys. What are some preferred ways to handle this where your application is being developed out in the open, by people outside of your core who need to “login” to work on protected functionality?

[dan.woda]

Hey again @brettski,

He have a delegated admin extension, but it doesn’t have full customizability. You can always build out your own admin dash with the management API.

Delegated Administration Extension v3

Hope this helps!

Thanks,
Dan

[brettski]

Hello again @dan.woda, thank you for the response. So this extension helps provide access to users in the Auth0 dashboard, though I don’t understand how this could help them run the software locally to develop it.

Is the practice to use dev keys from a dev tenant, or mock out the login? I hope my question makes sense. In many cases we will not know know who these people are who may want to contribute to the site.

[dan.woda]

Can you give an example of an action that your developers are trying to take? What do they need access to? I think I misunderstood your situation with my initial response.

[brettski]

split discussion, that’s a nice feature!

Back to this. My thoughts are around any areas of the site which require authentication. External developers will need the ability to test what the are working on, which means needing an access_token to validate they are active and have permissions for that section of the site.

I haven’t done this in the open before using an auth provider. Does this make sense or do you require a more concrete example?

Brett

[dan.woda]

@brettski,

Yes it is! Helps keep things focused.

On to your question. I think I understand what you mean, let me confirm. For example, an open source developer that you do not inherently trust needs to test their application against an API you have set up. You want to allow them to test this, but you do not want to let your API be open to just anyone.

In a case like this, you would want to set up a third party application in the dashboard, and you can give the developer the client id and secret to do their testing. You would set up a new application for each developer, that way you can monitor what requests are coming from which developer. Does that make sense?

I may be misunderstanding the use-case, if so please clarify further.

Thanks,
Dan

[that]

Hey @dan.woda!

@brettski and I are working together on this but I’d thought I’d ask the question a bit different than he did.

It’s not really about trust of any individual but more about overall secret management and making sure we do the right thing with our production app/api keys.

Given that, to support our open source efforts people either need a way to configure the website with a set of keys, or we need to implement some serious mocking to fake things out. Granted there are prolly 1k ways to accomplish this but security is important for us but we also don’t want to make it impossible for the community to participate.

We’re just not sure what approach we should be taking and maybe it’s as simple as a separate app/api setup in auth0 that we just pass out on demand but that felt weird.

Mind you, we’re not security experts by any means, and looking to ya’ll for some help and guidance as we just don’t want to comprise our production system and the communities trust.

Thanks,
Clark Sell

[dan.woda]

Hi @that!

I think I have a better grasp of the situation now. I am thinking you would be okay creating a seperate dev tenant, this would seperate your users from the open source developers, but allow for testing. Let me reach out to the field team and get their feedback. I’ll update here when I hear back.

Thanks,
Dan

[that]

@dan.woda we appreciate that. It feels like it comes down to key management assuming we want folks to be able to sign-in and do development on those parts of the website. We certainly aren’t the only folks trying to do something like this.

For reference - GitHub - ThatConference/that-website: THAT Conference

Also, if we really want to complicate matters, our PR process with Zeit’s now, creates a new subdomain for every pr. being able to use a wildcard dev, domain for that process against an auth0 dev tenant would be nice as well. That would also help ensure keys don’t get leaked too.

Thanks!
Clark

[dan.woda]

Okay, I’m back.

The guidance given to me is to have devs create their own free Auth0 accounts and provide them with instructions for configuring the application.

Would that work for you?

[that]

Interesting approach.

That easily works ( could be totally wrong here ) in the scenario where it’s just the website but then you add an api, and now you’ve got a lot of setup to do, scopes, domains, app/api. I know it took us a bit of time just to get things right.

For folks who just want to contribute, that feels like a huge hurdle, just to get up and running. That could be a turn off.

Hard balance between the complexity of security and that of making it easy for folks.

[dan.woda]

That was my thought too. I took at look at the repo, and there is already some necessary configuration and you don’t want to discourage contribution by making configuration too cumbersome.

Let me see what else I can gather.

[dan.woda]

Here is what I was told:

They definitely do not want to be doing development work using their production tenant, so that would be an absolute first step.

You should definitely point them to the auth0-deploy-cli .
This will make it easier to repeat configuration of the Auth0 tenant as code.

the Zeit subdomain can just be a variable in their configuration

Having a tenant per dev may be more effort than they really need… Considering this is a react application I wouldn’t imagine they are working with any secret values. They are fine to share the application’s Client ID This is public information.

[that]

#1 - agree. for sure.
#2 - will check it out… great to know.
#2 - awesome.
#4 - …and teach me, I would love to be a little less confused. Just when I think I get it, “only client id” and I don’t understand if that’s really possible. Following ya’lls example nextjs-auth0/next.config.js at master_OLD · auth0/nextjs-auth0 · GitHub they need a lot more than just the client id. Granted most of that, like the domain isn’t a big deal… but the client secret is there. I would assume they need that as well.