5 ms·

Another issue with OAuth is the assumption that the browser part of the flow (where the real user enters their username and password on the issuer website) is a

by davedx 3y ago

Another issue with OAuth is the assumption that the browser part of the flow (where the real user enters their username and password on the issuer website) is actually done by a real user. When I was trying to automate EV charging, I looked at quite a few OAuth implementations and many of them were doing things like storing the user's credentials (including their password) then doing the entire OAuth flow with browser automation. I imagine this was the tip of the iceberg. These days with a lot of non-standards-compliant OAuth implementations behind me, my conclusion is a lot of it is a giant waste of time, and it often adds completely pointless complexity for many of the cases it's used for. And as shown in the article, all the complexity often adds exploit vectors. For 90% of API use cases just issue a revokable Bearer Token and be done with it. You are not an app platform!!! [Qualifier: the EV API's I experimented with were a good use-case for OAuth, as they were user-first, based on mobile apps authenticated with user/password credentials. But I've worked with a lot of third party vendor API's where it was purely server-to-server access, but for some reason wrapped in OAuth... because... architects and compliance something something]

deleted 3y ago
[deleted]
lathiat 3y ago
The oaith spec requires a callback URL to work and usually that url has to be “registered”/authorised with the server. Most of these apps are using the api “unofficially” and the only way to do that is with browser automation. Otherwise once the login is complete the redirect with the authorised token won’t get to your app - it will go to the official website or app. They then pluck the authorised token out of the cookie store.
- davedx 3y ago
  Not really. The libraries should do what my own app does: render the vendor website (Tesla or whoever) in a browser window and let the user enter their creds securely. You can then capture the auth code from the redirect just fine. There are right and wrong ways to do OAuth both in server and client, and many, many implementations do it wrong.
  - randomdata 3y ago
    > You can then capture the auth code from the redirect just fine. Not when you don't have an 'official' redirect URL.
    - codetrotter 3y ago
      If you control the client, you can. Because when you get the redirect response, you then take the auth code that is included there, and you don’t follow the redirect. Then you send the auth code to your backend instead.
      - randomdata 3y ago
        Typically if you farm the job out to a browser, per the discussion, then you don't have control over the client.
        codetrotter 3y ago
        I took it to mean that they render the login page in a web view still controlled by their app
    - davedx 3y ago
      Right, so my app is an electron app, and you can hook into the redirect. It’s still a little bit hacking the flow but not as bad as full browser automation
  - lathiat 3y ago
    That works for GUI apps I agree though doesn’t work for server side stuff. Which I suspect the software the OP meant is. But yes better than storing the password if you are on a desktop.
Semaphor 3y ago
> it was purely server-to-server access, but for some reason wrapped in OAuth... because... architects and compliance something something] That sometimes feels like the bane of my existence. Everything has to be OAuth and use refresh tokens, certificates etc. when I never care or use any user data. No one logs in. This is all our server talking to their server. Revokable Bearer Tokens used to be used, but every API that updates switched to OAuth which makes everything more complicated.
- krooj 3y ago
  This is what the client_credentials grant flow is intended for. If you're using any interactive grant flows to secure S2S communications, you're doing it wrong.
figassis 3y ago
What I hate about OAuth is how slow and cumbersome it makes the process across the web. Everything requires login with google for example, but that flow is so slow that it’s what I dread the most of all auth. Especially when I see the page reloading multiple times because it wants so many other things besides just auth.
- PH95VuimJjqBqy 3y ago
  If you have an IAM with underlying IDP's it will legit be a stack of redirects with callbacks, sometimes deeper than 1 or 2. It's nuts.
caseysoftware 3y ago
> I've worked with a lot of third party vendor API's where it was purely server-to-server access, but for some reason wrapped in OAuth... because... architects and compliance something something As someone who's implemented a bunch of these.. It's less about compliance and more about getting everything "speaking OAuth" Once you've converted your user-facing flows to use OAuth and you're dealing with scopes, tokens, etc, converting the backend to also use it makes a lot of sense. Then you have ONE path for token validation, inspecting/validating scopes, and client id/secret issuance whether you're on the front or back end. Having one model for people to understand makes things tangibly simpler and shrinks the libraries/tools you need. If you ONLY have backend (service to service) flows with a simple authZ model, OAuth is usually overkill.
- PH95VuimJjqBqy 3y ago
  OAuth is usually overkill, period. There are only two real use cases for the complexity of OAuth. 1. SAAS model and you're allowing your customers to use their own IDP 2. You really and truly have a lot of disparate internal systems that need SSO. And 2 generally has better solutions.
  - sleepybrett 3y ago
    > And 2 generally has better solutions. you fail to mention them.
    - PH95VuimJjqBqy 3y ago
      because it depends on the specific needs. It could be as simple as LDAP integration or as complex as OAuth.
      - marcosdumay 3y ago
        One really shitty thing is that people keep inventing those badly-though protocols like OAuth, and yet nobody (as in no browser) ever implemented LDAP over the web.
marcosdumay 3y ago
> because... architects and compliance something something At work the tooling we use for our services outright requires OAuth if you want authentication. And yeah, that's a large factor implying we should use something else, but there are many coordination problems for that. I imagine plenty of people have a similar problem. Anyway, if your client is saving your password, then I'd say that's not a good use-case for OAuth. At this point I'm not sure there exist a good use-case for OAuth.
judge2020 3y ago
Tesla only just recently opened the ability to be an official oauth application, so all apps before now either required storing username+password or the long-lived token it sends back once you authenticate.

by davedx 3y ago

deleted 3y ago

[deleted]

lathiat 3y ago

The oaith spec requires a callback URL to work and usually that url has to be “registered”/authorised with the server. Most of these apps are using the api “unofficially” and the only way to do that is with browser automation. Otherwise once the login is complete the redirect with the authorised token won’t get to your app - it will go to the official website or app. They then pluck the authorised token out of the cookie store.

davedx 3y ago
Not really. The libraries should do what my own app does: render the vendor website (Tesla or whoever) in a browser window and let the user enter their creds securely. You can then capture the auth code from the redirect just fine. There are right and wrong ways to do OAuth both in server and client, and many, many implementations do it wrong.
- randomdata 3y ago
  > You can then capture the auth code from the redirect just fine. Not when you don't have an 'official' redirect URL.
  - codetrotter 3y ago
    If you control the client, you can. Because when you get the redirect response, you then take the auth code that is included there, and you don’t follow the redirect. Then you send the auth code to your backend instead.
    - randomdata 3y ago
      Typically if you farm the job out to a browser, per the discussion, then you don't have control over the client.
      - codetrotter 3y ago
        I took it to mean that they render the login page in a web view still controlled by their app
  - davedx 3y ago
    Right, so my app is an electron app, and you can hook into the redirect. It’s still a little bit hacking the flow but not as bad as full browser automation
- lathiat 3y ago
  That works for GUI apps I agree though doesn’t work for server side stuff. Which I suspect the software the OP meant is. But yes better than storing the password if you are on a desktop.

Semaphor 3y ago

> it was purely server-to-server access, but for some reason wrapped in OAuth... because... architects and compliance something something] That sometimes feels like the bane of my existence. Everything has to be OAuth and use refresh tokens, certificates etc. when I never care or use any user data. No one logs in. This is all our server talking to their server. Revokable Bearer Tokens used to be used, but every API that updates switched to OAuth which makes everything more complicated.

krooj 3y ago
This is what the client_credentials grant flow is intended for. If you're using any interactive grant flows to secure S2S communications, you're doing it wrong.

figassis 3y ago

What I hate about OAuth is how slow and cumbersome it makes the process across the web. Everything requires login with google for example, but that flow is so slow that it’s what I dread the most of all auth. Especially when I see the page reloading multiple times because it wants so many other things besides just auth.

PH95VuimJjqBqy 3y ago
If you have an IAM with underlying IDP's it will legit be a stack of redirects with callbacks, sometimes deeper than 1 or 2. It's nuts.

caseysoftware 3y ago

> I've worked with a lot of third party vendor API's where it was purely server-to-server access, but for some reason wrapped in OAuth... because... architects and compliance something something As someone who's implemented a bunch of these.. It's less about compliance and more about getting everything "speaking OAuth" Once you've converted your user-facing flows to use OAuth and you're dealing with scopes, tokens, etc, converting the backend to also use it makes a lot of sense. Then you have ONE path for token validation, inspecting/validating scopes, and client id/secret issuance whether you're on the front or back end. Having one model for people to understand makes things tangibly simpler and shrinks the libraries/tools you need. If you ONLY have backend (service to service) flows with a simple authZ model, OAuth is usually overkill.

PH95VuimJjqBqy 3y ago
OAuth is usually overkill, period. There are only two real use cases for the complexity of OAuth. 1. SAAS model and you're allowing your customers to use their own IDP 2. You really and truly have a lot of disparate internal systems that need SSO. And 2 generally has better solutions.
- sleepybrett 3y ago
  > And 2 generally has better solutions. you fail to mention them.
  - PH95VuimJjqBqy 3y ago
    because it depends on the specific needs. It could be as simple as LDAP integration or as complex as OAuth.
    - marcosdumay 3y ago
      One really shitty thing is that people keep inventing those badly-though protocols like OAuth, and yet nobody (as in no browser) ever implemented LDAP over the web.

marcosdumay 3y ago

> because... architects and compliance something something At work the tooling we use for our services outright requires OAuth if you want authentication. And yeah, that's a large factor implying we should use something else, but there are many coordination problems for that. I imagine plenty of people have a similar problem. Anyway, if your client is saving your password, then I'd say that's not a good use-case for OAuth. At this point I'm not sure there exist a good use-case for OAuth.

judge2020 3y ago

Tesla only just recently opened the ability to be an official oauth application, so all apps before now either required storing username+password or the long-lived token it sends back once you authenticate.