I implemented a Netlify OAuth (not Identity) Auth Provider, but I'm not Sure I Should Have ... and Why

Get Help and Help Others Show & Tell
1

I need some advice …

I have an idea for a new RedwoodJS App that would track Netlify Deploy stats. The already show Build stats, but not the stats I want – and know the numbers are there.

Originally, I was going to do Auth0 auth and have build plugins and functions “do the work” – and they still will.

But, I realized, if I need the Netlify site ids, why not use the NetlifyAPI to authorize over OAuth2, get the access token, and fetch the sites.The users signup/in will always be a Netlify user. Note: this is different from the current netlify provider, which is NetlifyIdentity.

So yesterday, I implemented a first pass at NetlifyOAuth in my branch of a redwood fork:

And it works:

output
output496×628 171 KB

But, once I have an access token (my access token … your access token) I can call any NetlifyAPI endpoint on your behalf. Their api doesn’t hide any info – it’s prety much an API into their dashboard. So not only delete sites but also when pulling back a site it exposes all my private envs. I can take your db token or any other secret:

netlify-api-sites-response
netlify-api-sites-response635×668 88.1 KB

So - I cannot in all good faith do that.

My only option might be to extract only the data I need (site ids, maybe deploy ids) and trust that I don’t store your accessToken … but seems too much responsibility as a developer. And you’ll just have to trust me :wink:

I’m going to go back to my original concept and not use the Netlify OAuth even though the experience would be nice to be able to auto setup sites and such.

It will be a better example of RW and Build Plugins and functions and that was my original intent/concept and experiment.

But, there is an example of OAuth with Netlify though I now also wonder that since it just returns a token, if I couldn’t have just extended a custom provider.

So, thoughts?

2 Likes
2

@dthyresson Woah, I have the same reaction to this it seems like you did – for the amount of access granted in the permissions/scope provided by a user during OAuth, this documentation/messaging/UX/scope-limiting-features feels way out of balance for my comfort zone. Now knowing this is the case I personally won’t be using Netlify OAuth to grant access for anything to anyone. Just yikes.

I did reach out directly to our contacts at Netlify. Haven’t heard back and this is probably something they’d need to elevate.

I’m going to go back to my original concept and not use the Netlify OAuth even though the experience would be nice to be able to auto setup sites and such.

^^ This would be my choice if I were you. Maybe GitHub could be a replacement for UX purposes – it won’t be 1to1 that potential users have an account but I bet it’s pretty close.

Thanks for posting about this. These things are important. And hopefully also inform the way we as a community should think about best practices for the Apps we build.

3

I mean I hope I am wrong (but relatively certain I’m not).

Can see that their CLI delete site:

https://github.com/netlify/cli/blob/master/src/commands/sites/delete.js

calls that api

https://github.com/netlify/cli/blob/master/src/commands/sites/delete.js#L84

and they import the same

as I did on my app’s api side:

{
  "name": "api",
  "version": "0.0.0",
  "private": true,
  "dependencies": {
    "@redwoodjs/api": "^0.13.0",
    "netlify": "^4.3.5",
    "node-fetch": "^2.6.0"
  }
}

and then they use that netlify api in

const API = require('netlify')

So … yeah. :thinking:

feels way out of balance for my comfort zone.

Yes. A limited or scope-governed API feels appropriate here – list my sites… but just my site names and ids and some basic metadata.

I also reached out to my Netlify contacts and hope to hear back tomorrow.

All in all not using Netlify OAuth will be better for my app – then non-Netlify users can sign up to view the dashboard say for a “team”.

And it’s a better demo of tech (webhooks, build plugins, functions, some jobs even) all under the RedwoodJS umbrella, so I’m actually happier …

… and I now know that I want to be super transparent in what I send from a plugin to the “data services” to ensure trust in the user.

Now knowing this is the case I personally won’t be using Netlify OAuth to grant access for anything to anyone.

Yeah, I cutoff Zapier and … I had an old Slack authorization from integrating a bot. The only authorized app I kept is the “Netlify CLI” which sorta tells you the power of that authorization :wink:

Again - I do hope I am wrong.

1 Like
4

Well, I was not wrong.

Netlify got back to me and

  • the token has all the permissions you do
  • should be treated as sensitively as your pwd
  • feature request for scoped tokens
  • should be working on in that later this year
  • in fact they were discussing this just last week

So there it is.

5

Well, yay/boo. I didn’t hear back on my batchannel to Netlify HQ. Might try again with more direct messaging. Something to the effect of:

This actuality:

  • the token has all the permissions you do (env var values, etc.)
  • should be treated as sensitively as your pwd

Makes this messaging dangerously misleading:

Screen Shot 2020-07-15 at 2.34.16 PM
Screen Shot 2020-07-15 at 2.34.16 PM442×524 139 KB

6

My contact there is Chris (Head of Support @ Netlify) and he said that Mathias brought up the exact concern (aka unscoped auth permissions) last week and said that it is on their radar to address.

Reading between the lines, it sounds similar to an area they’ve addressed with giving options with sensitive envs to teams or restricting access to deploy previews – see: https://www.netlify.com/blog/2020/05/19/environment-variables-and-preview-deploys-get-a-boost/

And also I imagine better team support: if you have a team account, how can you give some people access to build but not edit envs or maybe edit sites.

But that’s my guess.

And yes – they could improve that message … especially in the light of the Twitter/Bitcoin “hack” today. Sometimes it may not be a hack per se – sometimes you’ve actually given apps permission to tweet on your behalf and you just don’t know it and trust the app won’t do anything malicious.

Screen Shot 2020-07-15 at 18.40.08

And if someone else hacks that app to get your tokens, well all bets are off.

1 Like