3 ms·

One of the things inspiring me to start work on LightSheets was when I tried to build an integration with Google Sheets API a couple of months ago and quickly e

by davedx 7y ago

One of the things inspiring me to start work on LightSheets was when I tried to build an integration with Google Sheets API a couple of months ago and quickly ended up down an OAuth rabbit hole for my non-interactive script. For building integrations, OAuth is nice for enhanced security for end users, but makes it harder for developers to build integrations. What I'm going to do with LightSheets is begin with simple per-spreadsheet token based authorization, so if you own a spreadsheet and want to build an integration it's very easy to do stuff with a single request per query. (I'll also implement a simple way to refresh the token in case it gets breached). Later on I will consider adding OAuth IF there's a use case for it. Interested in feedback from others about whether this is a good idea or not.

tyingq 7y ago
Maybe consider a configurable option for the token to only work as a POST payload, versus a url parameter. When they get passed around as urls in email, etc, they tend to get exposed pretty quickly. Breaks standard REST, but... Or maybe some shared secret challenge/response to get a time limited ticket?
- jmull 7y ago
  I wonder if a header would be a good place for a token. It won't get exposed like a URL parameter and doesn't misuse the body/POST.
- davedx 7y ago
  I'll almost certainly have it only allowed in headers irregardless of the HTTP verb used. This does mean you won't be able to use your browser to test GET's, but this feature is squarely aimed at developers who will probably be using a Postman like tool to test with.
  - cwivbly 7y ago
    > I'll almost certainly have it only allowed in headers irregardless of the HTTP verb used. This does mean you won't be able to use your browser to test GET's, There is very probably a way to (ab)use HTTP Auth for this such that it's still possible to test GETs with simple URL strings or links in a browser.
janpot 7y ago
> I'll also implement a simple way to refresh the token in case it gets breached I'd advise to implemented this in a way that you can have at least 2 tokens valid at any given time. So that you give your users the chance to rotate them without downtime.
- dugmartin 7y ago
  Or N tokens with a note field so that if you have multiple integrations you can assign one to each or share them - much nicer when you want to invoke access or roll tokens.
  - deleted 7y ago
    [deleted]
- davedx 7y ago
  Nice idea, thanks for the feedback.
magicalhippo 7y ago
That's just the way Google chooses to use OAuth when handling user data. OAuth works just fine for machine-to-machine too, see f.ex https://developers.google.com/identity/protocols/OAuth2ServiceAccount https://developers.google.com/identity/protocols/OAuth2Servi...
RileyJames 7y ago
Good for developers, but no necessarily end users. Even if you intend this only for development purposes, or for technical users, without doubt, some developers will ship their integrations to non-technical end users with instructions to: log into the dev portal, generate a token, add the token here, upload certificate, etc, etc. As simple as that is, it causes headaches non-technical users, which will end up in the support queue. Hence OAuth. But now you have an easy way, and a hard way, and the easy way is how every developer will begin their integration. You'll need to incentivize, or gatekeep, in order to have them complete their integration with OAuth.

by davedx 7y ago

tyingq 7y ago

Maybe consider a configurable option for the token to only work as a POST payload, versus a url parameter. When they get passed around as urls in email, etc, they tend to get exposed pretty quickly. Breaks standard REST, but... Or maybe some shared secret challenge/response to get a time limited ticket?

jmull 7y ago
I wonder if a header would be a good place for a token. It won't get exposed like a URL parameter and doesn't misuse the body/POST.
davedx 7y ago
I'll almost certainly have it only allowed in headers irregardless of the HTTP verb used. This does mean you won't be able to use your browser to test GET's, but this feature is squarely aimed at developers who will probably be using a Postman like tool to test with.
- cwivbly 7y ago
  > I'll almost certainly have it only allowed in headers irregardless of the HTTP verb used. This does mean you won't be able to use your browser to test GET's, There is very probably a way to (ab)use HTTP Auth for this such that it's still possible to test GETs with simple URL strings or links in a browser.

janpot 7y ago

> I'll also implement a simple way to refresh the token in case it gets breached I'd advise to implemented this in a way that you can have at least 2 tokens valid at any given time. So that you give your users the chance to rotate them without downtime.

dugmartin 7y ago
Or N tokens with a note field so that if you have multiple integrations you can assign one to each or share them - much nicer when you want to invoke access or roll tokens.
- deleted 7y ago
  [deleted]
davedx 7y ago
Nice idea, thanks for the feedback.

magicalhippo 7y ago

That's just the way Google chooses to use OAuth when handling user data. OAuth works just fine for machine-to-machine too, see f.ex https://developers.google.com/identity/protocols/OAuth2ServiceAccount https://developers.google.com/identity/protocols/OAuth2Servi...

RileyJames 7y ago

Good for developers, but no necessarily end users. Even if you intend this only for development purposes, or for technical users, without doubt, some developers will ship their integrations to non-technical end users with instructions to: log into the dev portal, generate a token, add the token here, upload certificate, etc, etc. As simple as that is, it causes headaches non-technical users, which will end up in the support queue. Hence OAuth. But now you have an easy way, and a hard way, and the easy way is how every developer will begin their integration. You'll need to incentivize, or gatekeep, in order to have them complete their integration with OAuth.