3 ms·

Oof - to clear a few things up: >There is no way to know that a specific OAuth call is made by a specific desktop client so the whole concept of a client secre

Oof - to clear a few things up: >There is no way to know that a specific OAuth call is made by a specific desktop client so the whole concept of a client secret is incoherent. What makes you think you can’t issue per-Client, client secrets at install time? And aside from the authorize call itself, every other OAuth2 call is authenticated to a user and client via the grant type used. >PKCE… overkill… you’re on a mobile platform in which case you can used authenticated https URLs that get captured by your native app. It’s explicitly because you cant guarantee that another app hasn’t hooked into your URLs that PKCE exists.

nightpool 4y ago
> What makes you think you can’t issue per-Client, client secrets at install time? I have in fact used systems like this—this is how OAuth works for Mastodon client apps. These are in fact pretty secure, and one of the reasons we don't implement PKCE for Mastodon (also because iirc it's annoying to enable in Doorkeeper or there are some gem version conflicts or something). This is required because Mastodon clients have to work with any random Mastodon server, without the client developer being aware of the server or having anything to do with it ahead of time. But again, the way most people think about client secrets is as authentication that a piece of software is what it says it is. This is how e.g. Github, Google, and every other major provider use OAuth. And this concept is what I'm saying is entirely incoherent with public apps like desktop or mobile apps. Registration like you propose opens up completely unauthenticated Sybil attacks on things that almost every other Oauth implementation prefers to keep locked down.
- throwaway290 4y ago
  Regarding your second paragraph, that was my understanding. But then Github has its own (well Microsoft's) native app that uses OAuth. So I can't see how they ensure an attacker doesn't extract credentials and crypto algorithms from VS Code distribution and get the ability to show any user a genuine "authorize VS Code?" prompt and steal their tokens. But I also doubt they'd just go with a security hole, so either they deal with it somehow or maybe it's not as much of an attack vector as I think...
- SgtBastard 4y ago
  > Registration like you propose opens up completely unauthenticated Sybil attacks I proposed no such thing. If it’s important to know which client made a particular call, then it’s important to authenticate that client. An old school CD-key can provide a one time shared secret to bootstrap a client install, or even a PBKDF if matched with a serial number to securely share the client secret. Most implementations are concerned with AuthN and AuthZ for users and don’t require these extra controls for client security (i.e. you don’t care which client instance a user interacts with) I was responding to erroneous assertions that these controls couldn’t be implemented.
throwaway290 4y ago
> What makes you think you can’t issue per-Client, client secrets at install time? IIRC I want to implement e.g. Github auth in my app I have one secret for my dev account, last I checked you couldn't just generate a client ID for every user... And with that in mind I can't be sure an attacker doesn't extract the "secret" from my app, then direct unsuspecting users to the prompt and intercepts their access keys.
- SgtBastard 4y ago
  Sure, these are limitations of GitHub’s implementation. There’s nothing in the spec that describes GitHub’s implementation of an Authorization server as one-client-key-per-app-binary as being a requirement (but I can see the convenience for the AS implementer). GP asked how to approach a (presumably) from scratch implementation compliant with OAuth 2.0. I provided him with one. Please don’t straw man my comments.
  - throwaway290 4y ago
    I asked, and this is my use case. I don't know what other common scenarios for OAuth2 implementation in a native app you'd expect, except for handling authenticating with major systems like Google, Github and so on... Thanks though.

nightpool 4y ago

> What makes you think you can’t issue per-Client, client secrets at install time? I have in fact used systems like this—this is how OAuth works for Mastodon client apps. These are in fact pretty secure, and one of the reasons we don't implement PKCE for Mastodon (also because iirc it's annoying to enable in Doorkeeper or there are some gem version conflicts or something). This is required because Mastodon clients have to work with any random Mastodon server, without the client developer being aware of the server or having anything to do with it ahead of time. But again, the way most people think about client secrets is as authentication that a piece of software is what it says it is. This is how e.g. Github, Google, and every other major provider use OAuth. And this concept is what I'm saying is entirely incoherent with public apps like desktop or mobile apps. Registration like you propose opens up completely unauthenticated Sybil attacks on things that almost every other Oauth implementation prefers to keep locked down.

throwaway290 4y ago
Regarding your second paragraph, that was my understanding. But then Github has its own (well Microsoft's) native app that uses OAuth. So I can't see how they ensure an attacker doesn't extract credentials and crypto algorithms from VS Code distribution and get the ability to show any user a genuine "authorize VS Code?" prompt and steal their tokens. But I also doubt they'd just go with a security hole, so either they deal with it somehow or maybe it's not as much of an attack vector as I think...
SgtBastard 4y ago
> Registration like you propose opens up completely unauthenticated Sybil attacks I proposed no such thing. If it’s important to know which client made a particular call, then it’s important to authenticate that client. An old school CD-key can provide a one time shared secret to bootstrap a client install, or even a PBKDF if matched with a serial number to securely share the client secret. Most implementations are concerned with AuthN and AuthZ for users and don’t require these extra controls for client security (i.e. you don’t care which client instance a user interacts with) I was responding to erroneous assertions that these controls couldn’t be implemented.

throwaway290 4y ago

> What makes you think you can’t issue per-Client, client secrets at install time? IIRC I want to implement e.g. Github auth in my app I have one secret for my dev account, last I checked you couldn't just generate a client ID for every user... And with that in mind I can't be sure an attacker doesn't extract the "secret" from my app, then direct unsuspecting users to the prompt and intercepts their access keys.

SgtBastard 4y ago
Sure, these are limitations of GitHub’s implementation. There’s nothing in the spec that describes GitHub’s implementation of an Authorization server as one-client-key-per-app-binary as being a requirement (but I can see the convenience for the AS implementer). GP asked how to approach a (presumably) from scratch implementation compliant with OAuth 2.0. I provided him with one. Please don’t straw man my comments.
- throwaway290 4y ago
  I asked, and this is my use case. I don't know what other common scenarios for OAuth2 implementation in a native app you'd expect, except for handling authenticating with major systems like Google, Github and so on... Thanks though.