4 ms·

I think oauth is abused as a way of protecting your API. Often it’s just an unnecessary complication which makes your API harder to use and your libraries bloat

by methyl 4y ago

I think oauth is abused as a way of protecting your API. Often it’s just an unnecessary complication which makes your API harder to use and your libraries bloated. If Stripe can get away with just public and secret key pair, there is a big chance it’s enough for you as well.

pbreit 4y ago
Amen! I do not understand the rash of OAuth-style authentication mechanisms for pure server-to-server applications.
- tehbeard 4y ago
  Simplicity on the the resource provider's end? So I implement separate IAM flows for my website, app and third party api access? Or... Make use of OAuth to standardize it, using code auth+pkce for web/app, and client credentials (not user/pass, this is client id + secret, scoped to permissions you want) for third party APIs. The scoping is so useful, api keys tend to ignore that, so platforms like digital ocean only give you an all or nothing key, meaning I can't plumb an acme client in to do DNS challenges, without also letting it spool up a VM...
  - pbreit 4y ago
    Simplicity on the client side. I didn’t understand the rest if your reply. Scoping is easy to implement on a user/key.
tremon 4y ago
What user authentication does Stripe handle? As a user I've interacted with Stripe's services a lot, but I've never needed to authenticate myself to them.
- pbreit 4y ago
  https://stripe.com/docs/api/authentication https://stripe.com/docs/api/authentication Even pure server-to-server applications with "no user involved" are starting to use OAuth authentication which I don't quite understand. https://www.verygoodsecurity.com/docs/payment-optimization/authentication https://www.verygoodsecurity.com/docs/payment-optimization/a...
  - DrBenCarson 4y ago
    the `client_credentials` grant is literally made for server-to-server applications
    - pbreit 4y ago
      But why bother with the extra call to request an access token? Makes everything harder for modest security gains.
      - loginatnine 4y ago
        Access tokens are short lived and can easily be revoked (when opaque). Sending your service credentials to every service is arguably less secure since they can have lesser security or log unwanted things.
        pbreit 4y ago
        Revocation is actually a major problem with JWTs.
deleted 4y ago
[deleted]
yoavm 4y ago
I totally agree with you and so I'll put a shameless plug here: I've created OAuth Hopper[0] exactly for this reason. It essentially takes a resource behind OAuth, strips OAuth from it and exposes it with Basic Access Authentication. I'm using it to let clients that don't support OAuth access services that force it. [0] https://github.com/bjesus/oauth-hopper/ https://github.com/bjesus/oauth-hopper/
gscott 4y ago
Twilio as well
rdegges 4y ago
I agree: https://www.rdegges.com/2015/why-i-love-basic-auth/ https://www.rdegges.com/2015/why-i-love-basic-auth/
d4mi3n 4y ago
I don’t really disagree with your statements, but I’d like to point out that: 1. Just because a large company does something does not make that thing safe or correct—especially when your risk appetite and attack surfaces are not the same. 2. OAuth has it’s place, but it alone isn’t enough to secure an API. With or without OAuth most applications need well defined identity management, authorization mechanisms (distinct from authentication mechanisms), and all the other pesky implementation details one needs to consider when there is a desire to guarantee the authenticity, integrity, and/or confidentiality of requests to and from said application.

by methyl 4y ago

pbreit 4y ago

Amen! I do not understand the rash of OAuth-style authentication mechanisms for pure server-to-server applications.

tehbeard 4y ago
Simplicity on the the resource provider's end? So I implement separate IAM flows for my website, app and third party api access? Or... Make use of OAuth to standardize it, using code auth+pkce for web/app, and client credentials (not user/pass, this is client id + secret, scoped to permissions you want) for third party APIs. The scoping is so useful, api keys tend to ignore that, so platforms like digital ocean only give you an all or nothing key, meaning I can't plumb an acme client in to do DNS challenges, without also letting it spool up a VM...
- pbreit 4y ago
  Simplicity on the client side. I didn’t understand the rest if your reply. Scoping is easy to implement on a user/key.

tremon 4y ago

What user authentication does Stripe handle? As a user I've interacted with Stripe's services a lot, but I've never needed to authenticate myself to them.

pbreit 4y ago
https://stripe.com/docs/api/authentication https://stripe.com/docs/api/authentication Even pure server-to-server applications with "no user involved" are starting to use OAuth authentication which I don't quite understand. https://www.verygoodsecurity.com/docs/payment-optimization/authentication https://www.verygoodsecurity.com/docs/payment-optimization/a...
- DrBenCarson 4y ago
  the `client_credentials` grant is literally made for server-to-server applications
  - pbreit 4y ago
    But why bother with the extra call to request an access token? Makes everything harder for modest security gains.
    - loginatnine 4y ago
      Access tokens are short lived and can easily be revoked (when opaque). Sending your service credentials to every service is arguably less secure since they can have lesser security or log unwanted things.
      - pbreit 4y ago
        Revocation is actually a major problem with JWTs.

deleted 4y ago

[deleted]

yoavm 4y ago

I totally agree with you and so I'll put a shameless plug here: I've created OAuth Hopper[0] exactly for this reason. It essentially takes a resource behind OAuth, strips OAuth from it and exposes it with Basic Access Authentication. I'm using it to let clients that don't support OAuth access services that force it. [0] https://github.com/bjesus/oauth-hopper/ https://github.com/bjesus/oauth-hopper/

gscott 4y ago

Twilio as well

rdegges 4y ago

I agree: https://www.rdegges.com/2015/why-i-love-basic-auth/ https://www.rdegges.com/2015/why-i-love-basic-auth/

d4mi3n 4y ago

I don’t really disagree with your statements, but I’d like to point out that: 1. Just because a large company does something does not make that thing safe or correct—especially when your risk appetite and attack surfaces are not the same. 2. OAuth has it’s place, but it alone isn’t enough to secure an API. With or without OAuth most applications need well defined identity management, authorization mechanisms (distinct from authentication mechanisms), and all the other pesky implementation details one needs to consider when there is a desire to guarantee the authenticity, integrity, and/or confidentiality of requests to and from said application.