4 ms·

Tangentially, anyone knows how to securely implement OAuth2 in a native client (like a desktop app)? How to deal with client secret?

nightpool 4y ago
depends on what you mean by "securely". Fundamentally, 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 completely incoherent. You just have to give up on the concept entirely. If you're worried about specific scenarios where a code could be "intercepted" between your server and the desktop app, you can use PKCE to make sure that no non-root program that's also running on the user's computer would be able to intercept the code, but usually that's overkill in most scenarios (either you're on a desktop platform in which case your token can just be read off of the disk, or you're on a mobile platform in which case you can use authenticated https URLs that get captured by your native app)
- SgtBastard 4y ago
  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.
- throwaway290 4y ago
  I think that's what the specs prescribe, yet it seems that desktop clients like VS Code work around that somehow...
sigwinch28 4y ago
A good starting point is https://auth0.com/docs/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use https://auth0.com/docs/get-started/authentication-and-author... > If the Application is a native app, then use the Authorization Code Flow with Proof Key for Code Exchange (PKCE). You could use the Authorization Code Flow with Proof Key for Code Exchange (PKCE) with a web server listening on localhost or you could use the Device Authorization Flow. I believe GitHub use the latter for the GitHub CLI.
- throwaway290 4y ago
  Following their flow at https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-proof-key-for-code-exchange-pkce https://auth0.com/docs/get-started/authentication-and-author...: > 1. The user clicks Login within the application. > 2. Your Auth0 Authorization Server redirects the user to the login and authorization prompt. > 3. The user authenticates using one of the configured login options and may see a consent page listing the permissions Auth0 will give to the application. Here's the problem as I see it: say I'm Acme inc. and I create an app that does this. The user logs in, sees "allow Acme to access your account", clicks OK, my app gets access token, all good. The problem is if a black hat does the exact same thing, with the authorization server and all, directs user to an interface that shows the exact same (and actually legit) "allow Acme to access your account" screen, except their code grabs the access token in the end. I'm not 100% sure how the flow suggested by auth0 is helpful in addressing this compared the flow where the client secret is just stored in the app (and is not actually a secret anymore). The secret is what can prove to OAuth server the identity of the client. If there's no secret it's impossible: the server can't know if that's actually a client I wrote or a client written by malicious attacker to mimic my client but to steal user's tokens, right? I guess I don't get something fundamental or it's not a problem that can be solved at all (not this way).
  - yencabulator 4y ago
    > The problem is if a black hat does the exact same thing, with the authorization server and all, directs user to an interface that shows the exact same (and actually legit) "allow Acme to access your account" screen, except their code grabs the access token in the end. If the attacker can make the user happily give them access, then yeah of course the sucker gets pwned. If you want to protect against this more, you can make your app talk to your own servers, which hold an extra secret, and tie the OAuth into the server instead of just the local app. It gets more complex quick, but hey that's OAuth for you...
SgtBastard 4y ago
The same way you deal with any secrets on a desktop: OS-supported crypto, like the CryptoAPI in Windows or if you really wanted to double down on security: password based key derivation functions or physically attached crypto hardware (like Yubico devices)
WirelessGigabit 4y ago
PKCE. No client secret needed.

nightpool 4y ago

depends on what you mean by "securely". Fundamentally, 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 completely incoherent. You just have to give up on the concept entirely. If you're worried about specific scenarios where a code could be "intercepted" between your server and the desktop app, you can use PKCE to make sure that no non-root program that's also running on the user's computer would be able to intercept the code, but usually that's overkill in most scenarios (either you're on a desktop platform in which case your token can just be read off of the disk, or you're on a mobile platform in which case you can use authenticated https URLs that get captured by your native app)

SgtBastard 4y ago
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.
throwaway290 4y ago
I think that's what the specs prescribe, yet it seems that desktop clients like VS Code work around that somehow...

sigwinch28 4y ago

A good starting point is https://auth0.com/docs/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use https://auth0.com/docs/get-started/authentication-and-author... > If the Application is a native app, then use the Authorization Code Flow with Proof Key for Code Exchange (PKCE). You could use the Authorization Code Flow with Proof Key for Code Exchange (PKCE) with a web server listening on localhost or you could use the Device Authorization Flow. I believe GitHub use the latter for the GitHub CLI.

throwaway290 4y ago
Following their flow at https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-proof-key-for-code-exchange-pkce https://auth0.com/docs/get-started/authentication-and-author...: > 1. The user clicks Login within the application. > 2. Your Auth0 Authorization Server redirects the user to the login and authorization prompt. > 3. The user authenticates using one of the configured login options and may see a consent page listing the permissions Auth0 will give to the application. Here's the problem as I see it: say I'm Acme inc. and I create an app that does this. The user logs in, sees "allow Acme to access your account", clicks OK, my app gets access token, all good. The problem is if a black hat does the exact same thing, with the authorization server and all, directs user to an interface that shows the exact same (and actually legit) "allow Acme to access your account" screen, except their code grabs the access token in the end. I'm not 100% sure how the flow suggested by auth0 is helpful in addressing this compared the flow where the client secret is just stored in the app (and is not actually a secret anymore). The secret is what can prove to OAuth server the identity of the client. If there's no secret it's impossible: the server can't know if that's actually a client I wrote or a client written by malicious attacker to mimic my client but to steal user's tokens, right? I guess I don't get something fundamental or it's not a problem that can be solved at all (not this way).
- yencabulator 4y ago
  > The problem is if a black hat does the exact same thing, with the authorization server and all, directs user to an interface that shows the exact same (and actually legit) "allow Acme to access your account" screen, except their code grabs the access token in the end. If the attacker can make the user happily give them access, then yeah of course the sucker gets pwned. If you want to protect against this more, you can make your app talk to your own servers, which hold an extra secret, and tie the OAuth into the server instead of just the local app. It gets more complex quick, but hey that's OAuth for you...

SgtBastard 4y ago

The same way you deal with any secrets on a desktop: OS-supported crypto, like the CryptoAPI in Windows or if you really wanted to double down on security: password based key derivation functions or physically attached crypto hardware (like Yubico devices)

WirelessGigabit 4y ago

PKCE. No client secret needed.