8 ms·

OAuth with Cloudflare workers on a statically generated site

183 points by vonadz 5y ago

jimhi 5y ago
Fantastic use of workers! I added the ability to do captcha submissions from my site and send alerts to slack myself. I opted not to go the worker route as I found the language a bit hard to use and I could get the same effect with just javascript pulling other dynamic javascript hosted elsewhere. (You can see an example with the submission form at the bottom of this page: https://mrsteinberg.com/how-to-kill-your-startup-co-founder-conflict/ https://mrsteinberg.com/how-to-kill-your-startup-co-founder-...)
- tyingq 5y ago
  > I opted not to go the worker route as I found the language a bit hard to use and I could get the same effect with just javascript pulling other dynamic javascript hosted elsewhere I'm confused by this since the default language for Workers is javascript. Do you mean their api is confusing?
  - adamkochanowicz 5y ago
    Same question.
  - jimhi 5y ago
    I answered above - looking at their site it appears there is much more documentation. It was hard to wrap my head around what it was doing / the APIs when I wrote this
- vonadz 5y ago
  Thanks! I'd like to explore adding debugging and warning alerts in the future. Right now it's kind of hard to tell if anything is broken, short of going through the registration process myself. If you're pulling javascript hosted somewhere else to your site, doesn't that expose your slack API key?
  - jimhi 5y ago
    I should have explained more. The javascript is dynamically created and hosted on S3. The keys, etc are safely on a server that runs to generate the file. I built this around the time Cloudflare first released workers, their documentation seems much less confusing now.
    - vonadz 5y ago
      I'm having a hard time understanding how a file hosted on S3 can send a request to Slack without exposing your API key. Can you elaborate on that? EDIT: guessing by the delay in response, someone just told all of HN they exposed their API key?
      - DangitBobby 5y ago
        My understanding is that they used cloud functions. Code is being executed on someone else's server, not the client, so the keys don't have to be shared with the client.
        vonadz 5y ago
        That would be the logical solution, but "The javascript is dynamically created and hosted on S3. The keys, etc are safely on a server that runs to generate the file" sounds a lot like they have a server where they build a .js file that is capable of querying Slack, then store that file on S3 for the website to pull whenever someone registers. In that case, the client is pulling a .js file that probably has the Slack API key in it.
- deleted 5y ago
  [deleted]
- ignoramous 5y ago
  > Fantastic use of workers! Well, when you think of Workers as Nginx, Squid, Memcached as-a-service, the possibilities simply present themselves. It is absolutely appalling that AWS has Lambda@Edge (relatively, uber expensive) and CloudFront Functions (uber lame) positioned against Workers. Full-stack week starting today, and it is very likely that Cloudflare launch Container support for Workers: https://blog.cloudflare.com/full-stack-week-2021/ https://blog.cloudflare.com/full-stack-week-2021/ Let's see if Adam Selipsky announces anything compelling at re:invent aloof from their Lightsail initiatives which are priced similar to Cloudflare (and cheap only if you're running toy products atop, but not any SaaS-like services).
intricatedetail 5y ago
Can you self host these workers? Otherwise you get vendor lock in which is a no go.
- vonadz 5y ago
  Self hosting would pretty much defeat the whole purpose of workers. The point is that you don't need to self host.
  - lsaferite 5y ago
    Their point is, can you mitigate vendor lock-in if you need to do so? The fact that you don't even consider that is a sad commentary in itself.
    - deleted 5y ago
      [deleted]
    - vonadz 5y ago
      If their point was can you mitigate vendor lock-in, they should have said that instead of asking about self-hosting. Saying you have vendor lock-in because you can't self-host something is very strange in the context of this article. I didn't make a point of vendor lock-in because migrating this process flow to a self-hosted HTTP server would take about 5 minutes. On top of that, this flow is going to be very similar for any vendor offering javascript functions. Perhaps it is my fault for not including a section discussing this, but I assumed that the audience for this would primarily be people understand basic javascript and could deduce the portability of the code by looking at it.
  - nicoburns 5y ago
    The point is that you don't need to host them in production. Being able to self-host is still very useful for testing and local development workflows
- ignoramous 5y ago
  Yes, miniflare [0] lets you run Workers locally, but I wouldn't treat it to production traffic. There's also Deno, which is very similar in technology to Workers [1]. Others are building "Workers" atop WebAssembly, and things are looking up on that front as well [2][3]. See also: https://github.com/debarshibasak/awesome-paas https://github.com/debarshibasak/awesome-paas [0] https://github.com/cloudflare/miniflare https://github.com/cloudflare/miniflare [1] https://deno.land https://deno.land [2] https://github.com/suborbital/atmo https://github.com/suborbital/atmo [3] https://github.com/krustlet/krustlet https://github.com/krustlet/krustlet
jbergstroem 5y ago
At my company we've been using workers extensively for routing, specific auth logic (including integration with Auth0) and more -- I guess moving towards an api gateway pattern. I loved it at first but its becoming very cumbersome to maintain. I'm currently migrating away from this pattern and try to keep logic closer to the application/code that leans on it. tl;dr: Orchestrating many cloudflare workers at scale has not been a great experience.
- vonadz 5y ago
  Yeah I don't find this at all surprising. Ultimately it's always a balance of what's worse to maintain, the reality (server) or the abstraction (workers).
noahmasur 5y ago
Why not just use Cloudflare Access for this? It’s the same thing for even less work (and it’s free for personal use).
- vonadz 5y ago
  Did you read the article?
- judge2020 5y ago
  This worker might be cheaper depending on how heavy your app is (eg. how many requests this worker triggers on) versus Access if you have >50 users.
- vonadz 5y ago
  Not quite sure why my other comment got flagged, it was a genuine question. If they had, and they still suggested this, I would inquire how that would be possible. It appeared to me that they had just read the title of the article and suggested something related to it. As far as I can tell, Cloudflare Access doesn't allow you to run arbitrary code in an environment that isn't exposed to the user, which is kind of the whole purpose of this setup. The sole purpose of the OAuth part of this operation is so that the user doesn't have to type in their email. Session persistence/selective access isn't relevant here, and that appears to be the only thing the Cloudflare Access really offers.
nawgz 5y ago
"Instead of using a single server with NGINX and an API on it, I use multiple external hosted services that cost more-per-request than an old-school setup with less portability and more vendor lock-in" This isn't even a technical accomplishment in any way, it's just slapping together a few managed services together to sign up someone for a newsletter. I cannot imagine being the one to maintain a signup flow like this, it certainly looks unnecessarily painful from here.
- vonadz 5y ago
  In regards to your quote, this is free and if I wanted to switch, I could just copy and paste the javascript into node with some minor tweaks. A big motivator for this was definitely just to try out Cloudflare workers and see how they are. I've set up countless servers for APIs. In terms of time, I'd say Cloudflare workers is a bit faster when you get over the initial learning curve. Obviously you could write a deploy script for a server and have it set up everything automatically, and I have done that in the past, but sometimes it's fun to try new things right? I never intended for this to come across as a technological accomplishment. I even end the article with "That’s pretty much it. It’s fairly simple with no real catches". I'm merely presenting what I thought would be useful information for some people. Personally I think maintaining a server is more work than maintaining this, but to each their own.
  - jffry 5y ago
    Thanks for sharing a small writeup of a neat thing you did! I think maybe the parent comment missed the context, which is that you wanted to add an email signup to an otherwise static site. In that context, setting up a VPS would now mean that you have to be responsible for a new pet, including security updates and monitoring. You would also have to change your deployment tooling / workflow to something quite different (pushing and restarting a running service, rather than just running aws s3 sync ...) Of course I don't think I would take this approach if I already had a backend service hosting a site, but I certainly would experiment with it if I were in your situation.
toastal 5y ago
To quote Sourcehut Pages Limitations (https://srht.site/limitations https://srht.site/limitations) > Connections from CloudFlare’s reverse proxy are dropped. Do not help one private company expand its control over all internet traffic. We really to not let the internet become so centralized.
- miyuru 5y ago
  Cloudflare is the only provider that I know of that provides IPv6 reverse proxy for free with fair limits. If it wasn't for them most of my sites won't be accessible for more than half of the internet.
  - guilhas 5y ago
    For "free" Also maybe there is a reasons for most of the internet not to care about ipv6 or current implementation, but that is another different big debate
    - ohyeshedid 5y ago
      What would those reasons be?
- GrayShade 5y ago
  Good, it's not up to Sourcehut to decide how I should expose a web service (or browse the Internet FWIW).
  - roberto 5y ago
    They're not? You're free to not use Sourcehut.
- stoned 5y ago
  SourceHut and its founder are the promulgators or a never ended stream of strong opinions and principled edicts that do little but alienate people. Drew’s solution to every problem is blocking and blackholing [0] which makes him seem weak and petty and suggests that by refusing to work constructively with people he’s mostly interested in strongarming and asserting dominance. I find it pretty hard to take him seriously and run from anything he’s associated with, even when I agree. There’s this concept called “non-violent communication” that he would be well-served to explore. https://github.com/makeworld-the-better-one/amfora/issues/199 https://github.com/makeworld-the-better-one/amfora/issues/19...
Lucasoato 5y ago
I absolute love the graph, really. When the idea is simple and easy, you don't need hundreds of tools, just the plain old paint is fine.
- vonadz 5y ago
  Thanks :) paint is the graphic editor I'm most proficient in!
fzaninotto 5y ago
I don't understand how you can log out using this method, and that's very concerning. You're basically logged in forever?
- vonadz 5y ago
  There is no logout because the login isn't really a login. All this is doing is using the user's permission to submit their email (registered on the OAuth service) to subscribe to the newsletter. Nothing in the browser is changing that could compromise your details.
techthumb 5y ago
From the article itself: ... one might think implementing OAuth sign up is relatively trivial; after all, you just need to write a fetch request that redirects the user to the OAuth page, then another request that sends their email to the newsletter service of choice to sign them up. Well, the issue is that in order to do the second step of that process, one needs to hit an API endpoint that requires authentication (an API key). That is essentially a password and not something you want to expose on the front end and give everyone access to. The OAuth Authorization Code Flow with Proof Key for Code Exchange (PKCE) solves this problem without needing a worker. This article Auth0 does a good job of explaining PKCE: https://auth0.com/docs/authorization/flows/authorization-code-flow-with-proof-key-for-code-exchange-pkce https://auth0.com/docs/authorization/flows/authorization-cod...
- vonadz 5y ago
  I think you misunderstood what I said. The API key I don't want to expose is the one that is required to register the user with the newsletter service, not the client key for the OAuth service.
  - DaiPlusPlus 5y ago
    OAuth doesn't use "API keys". Please clarify.
    - vonadz 5y ago
      "not the client key for the OAuth service" OAuth uses a client key and/or a client secret, for the application that is requesting access on behalf of the client.
      - DaiPlusPlus 5y ago
        OAuth + OIDC only uses client-secrets when using the client_credentials flow, which is only for us with non-human software, or when a client needs to authenticate and authorize itself independently of any human user. When humans are involved you won't be using client_credentials, you'll be using 'implicit' or 'code' (preferably with PKCE) - but ONLY when the client can actually safely store secrets - so static-website SPAs simply can't. While non-human client-credentials can be used in-conjunction with a human-user's credentials it's largely unnecessary as an unauthorized client wouldn't be able to authenticate with a human-user because the redirect_uri sent from the client would be rejected automatically (and if that worked, there's always 'aud' audience filtering too), so the human-user wouldn't even be prompted to authenticate, they'd get an error message.

183 points by vonadz 5y ago

Fantastic use of workers! I added the ability to do captcha submissions from my site and send alerts to slack myself. I opted not to go the worker route as I found the language a bit hard to use and I could get the same effect with just javascript pulling other dynamic javascript hosted elsewhere. (You can see an example with the submission form at the bottom of this page: https://mrsteinberg.com/how-to-kill-your-startup-co-founder-conflict/ https://mrsteinberg.com/how-to-kill-your-startup-co-founder-...)

tyingq 5y ago
> I opted not to go the worker route as I found the language a bit hard to use and I could get the same effect with just javascript pulling other dynamic javascript hosted elsewhere I'm confused by this since the default language for Workers is javascript. Do you mean their api is confusing?
- adamkochanowicz 5y ago
  Same question.
- jimhi 5y ago
  I answered above - looking at their site it appears there is much more documentation. It was hard to wrap my head around what it was doing / the APIs when I wrote this
vonadz 5y ago
Thanks! I'd like to explore adding debugging and warning alerts in the future. Right now it's kind of hard to tell if anything is broken, short of going through the registration process myself. If you're pulling javascript hosted somewhere else to your site, doesn't that expose your slack API key?
- jimhi 5y ago
  I should have explained more. The javascript is dynamically created and hosted on S3. The keys, etc are safely on a server that runs to generate the file. I built this around the time Cloudflare first released workers, their documentation seems much less confusing now.
  - vonadz 5y ago
    I'm having a hard time understanding how a file hosted on S3 can send a request to Slack without exposing your API key. Can you elaborate on that? EDIT: guessing by the delay in response, someone just told all of HN they exposed their API key?
    - DangitBobby 5y ago
      My understanding is that they used cloud functions. Code is being executed on someone else's server, not the client, so the keys don't have to be shared with the client.
      - vonadz 5y ago
        That would be the logical solution, but "The javascript is dynamically created and hosted on S3. The keys, etc are safely on a server that runs to generate the file" sounds a lot like they have a server where they build a .js file that is capable of querying Slack, then store that file on S3 for the website to pull whenever someone registers. In that case, the client is pulling a .js file that probably has the Slack API key in it.
deleted 5y ago
[deleted]
ignoramous 5y ago
> Fantastic use of workers! Well, when you think of Workers as Nginx, Squid, Memcached as-a-service, the possibilities simply present themselves. It is absolutely appalling that AWS has Lambda@Edge (relatively, uber expensive) and CloudFront Functions (uber lame) positioned against Workers. Full-stack week starting today, and it is very likely that Cloudflare launch Container support for Workers: https://blog.cloudflare.com/full-stack-week-2021/ https://blog.cloudflare.com/full-stack-week-2021/ Let's see if Adam Selipsky announces anything compelling at re:invent aloof from their Lightsail initiatives which are priced similar to Cloudflare (and cheap only if you're running toy products atop, but not any SaaS-like services).

intricatedetail 5y ago

Can you self host these workers? Otherwise you get vendor lock in which is a no go.

vonadz 5y ago
Self hosting would pretty much defeat the whole purpose of workers. The point is that you don't need to self host.
- lsaferite 5y ago
  Their point is, can you mitigate vendor lock-in if you need to do so? The fact that you don't even consider that is a sad commentary in itself.
  - deleted 5y ago
    [deleted]
  - vonadz 5y ago
    If their point was can you mitigate vendor lock-in, they should have said that instead of asking about self-hosting. Saying you have vendor lock-in because you can't self-host something is very strange in the context of this article. I didn't make a point of vendor lock-in because migrating this process flow to a self-hosted HTTP server would take about 5 minutes. On top of that, this flow is going to be very similar for any vendor offering javascript functions. Perhaps it is my fault for not including a section discussing this, but I assumed that the audience for this would primarily be people understand basic javascript and could deduce the portability of the code by looking at it.
- nicoburns 5y ago
  The point is that you don't need to host them in production. Being able to self-host is still very useful for testing and local development workflows
ignoramous 5y ago
Yes, miniflare [0] lets you run Workers locally, but I wouldn't treat it to production traffic. There's also Deno, which is very similar in technology to Workers [1]. Others are building "Workers" atop WebAssembly, and things are looking up on that front as well [2][3]. See also: https://github.com/debarshibasak/awesome-paas https://github.com/debarshibasak/awesome-paas [0] https://github.com/cloudflare/miniflare https://github.com/cloudflare/miniflare [1] https://deno.land https://deno.land [2] https://github.com/suborbital/atmo https://github.com/suborbital/atmo [3] https://github.com/krustlet/krustlet https://github.com/krustlet/krustlet

jbergstroem 5y ago

At my company we've been using workers extensively for routing, specific auth logic (including integration with Auth0) and more -- I guess moving towards an api gateway pattern. I loved it at first but its becoming very cumbersome to maintain. I'm currently migrating away from this pattern and try to keep logic closer to the application/code that leans on it. tl;dr: Orchestrating many cloudflare workers at scale has not been a great experience.

vonadz 5y ago
Yeah I don't find this at all surprising. Ultimately it's always a balance of what's worse to maintain, the reality (server) or the abstraction (workers).

noahmasur 5y ago

Why not just use Cloudflare Access for this? It’s the same thing for even less work (and it’s free for personal use).

vonadz 5y ago
Did you read the article?
judge2020 5y ago
This worker might be cheaper depending on how heavy your app is (eg. how many requests this worker triggers on) versus Access if you have >50 users.
vonadz 5y ago
Not quite sure why my other comment got flagged, it was a genuine question. If they had, and they still suggested this, I would inquire how that would be possible. It appeared to me that they had just read the title of the article and suggested something related to it. As far as I can tell, Cloudflare Access doesn't allow you to run arbitrary code in an environment that isn't exposed to the user, which is kind of the whole purpose of this setup. The sole purpose of the OAuth part of this operation is so that the user doesn't have to type in their email. Session persistence/selective access isn't relevant here, and that appears to be the only thing the Cloudflare Access really offers.

nawgz 5y ago

"Instead of using a single server with NGINX and an API on it, I use multiple external hosted services that cost more-per-request than an old-school setup with less portability and more vendor lock-in" This isn't even a technical accomplishment in any way, it's just slapping together a few managed services together to sign up someone for a newsletter. I cannot imagine being the one to maintain a signup flow like this, it certainly looks unnecessarily painful from here.

vonadz 5y ago
In regards to your quote, this is free and if I wanted to switch, I could just copy and paste the javascript into node with some minor tweaks. A big motivator for this was definitely just to try out Cloudflare workers and see how they are. I've set up countless servers for APIs. In terms of time, I'd say Cloudflare workers is a bit faster when you get over the initial learning curve. Obviously you could write a deploy script for a server and have it set up everything automatically, and I have done that in the past, but sometimes it's fun to try new things right? I never intended for this to come across as a technological accomplishment. I even end the article with "That’s pretty much it. It’s fairly simple with no real catches". I'm merely presenting what I thought would be useful information for some people. Personally I think maintaining a server is more work than maintaining this, but to each their own.
- jffry 5y ago
  Thanks for sharing a small writeup of a neat thing you did! I think maybe the parent comment missed the context, which is that you wanted to add an email signup to an otherwise static site. In that context, setting up a VPS would now mean that you have to be responsible for a new pet, including security updates and monitoring. You would also have to change your deployment tooling / workflow to something quite different (pushing and restarting a running service, rather than just running aws s3 sync ...) Of course I don't think I would take this approach if I already had a backend service hosting a site, but I certainly would experiment with it if I were in your situation.

toastal 5y ago

To quote Sourcehut Pages Limitations (https://srht.site/limitations https://srht.site/limitations) > Connections from CloudFlare’s reverse proxy are dropped. Do not help one private company expand its control over all internet traffic. We really to not let the internet become so centralized.

miyuru 5y ago
Cloudflare is the only provider that I know of that provides IPv6 reverse proxy for free with fair limits. If it wasn't for them most of my sites won't be accessible for more than half of the internet.
- guilhas 5y ago
  For "free" Also maybe there is a reasons for most of the internet not to care about ipv6 or current implementation, but that is another different big debate
  - ohyeshedid 5y ago
    What would those reasons be?
GrayShade 5y ago
Good, it's not up to Sourcehut to decide how I should expose a web service (or browse the Internet FWIW).
- roberto 5y ago
  They're not? You're free to not use Sourcehut.
stoned 5y ago
SourceHut and its founder are the promulgators or a never ended stream of strong opinions and principled edicts that do little but alienate people. Drew’s solution to every problem is blocking and blackholing [0] which makes him seem weak and petty and suggests that by refusing to work constructively with people he’s mostly interested in strongarming and asserting dominance. I find it pretty hard to take him seriously and run from anything he’s associated with, even when I agree. There’s this concept called “non-violent communication” that he would be well-served to explore. https://github.com/makeworld-the-better-one/amfora/issues/199 https://github.com/makeworld-the-better-one/amfora/issues/19...

Lucasoato 5y ago

I absolute love the graph, really. When the idea is simple and easy, you don't need hundreds of tools, just the plain old paint is fine.

vonadz 5y ago
Thanks :) paint is the graphic editor I'm most proficient in!

fzaninotto 5y ago

I don't understand how you can log out using this method, and that's very concerning. You're basically logged in forever?

vonadz 5y ago
There is no logout because the login isn't really a login. All this is doing is using the user's permission to submit their email (registered on the OAuth service) to subscribe to the newsletter. Nothing in the browser is changing that could compromise your details.

techthumb 5y ago

From the article itself: ... one might think implementing OAuth sign up is relatively trivial; after all, you just need to write a fetch request that redirects the user to the OAuth page, then another request that sends their email to the newsletter service of choice to sign them up. Well, the issue is that in order to do the second step of that process, one needs to hit an API endpoint that requires authentication (an API key). That is essentially a password and not something you want to expose on the front end and give everyone access to. The OAuth Authorization Code Flow with Proof Key for Code Exchange (PKCE) solves this problem without needing a worker. This article Auth0 does a good job of explaining PKCE: https://auth0.com/docs/authorization/flows/authorization-code-flow-with-proof-key-for-code-exchange-pkce https://auth0.com/docs/authorization/flows/authorization-cod...

vonadz 5y ago
I think you misunderstood what I said. The API key I don't want to expose is the one that is required to register the user with the newsletter service, not the client key for the OAuth service.
- DaiPlusPlus 5y ago
  OAuth doesn't use "API keys". Please clarify.
  - vonadz 5y ago
    "not the client key for the OAuth service" OAuth uses a client key and/or a client secret, for the application that is requesting access on behalf of the client.
    - DaiPlusPlus 5y ago
      OAuth + OIDC only uses client-secrets when using the client_credentials flow, which is only for us with non-human software, or when a client needs to authenticate and authorize itself independently of any human user. When humans are involved you won't be using client_credentials, you'll be using 'implicit' or 'code' (preferably with PKCE) - but ONLY when the client can actually safely store secrets - so static-website SPAs simply can't. While non-human client-credentials can be used in-conjunction with a human-user's credentials it's largely unnecessary as an unauthorized client wouldn't be able to authenticate with a human-user because the redirect_uri sent from the client would be rejected automatically (and if that worked, there's always 'aud' audience filtering too), so the human-user wouldn't even be prompted to authenticate, they'd get an error message.