4 ms·

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-s

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...
  - throwaway290 4y ago
    Yeah, but my server can't tell an impostor either if it fakes my client well enough. Anyway, good point.
- sigwinch28 4y ago
  "Sign in with X" can and does get abused: https://news.ycombinator.com/item?id=33917962 https://news.ycombinator.com/item?id=33917962 Getting a user to log in on a malicious app which has legitimate OAuth client credentials is usually game over, yes.

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...
- throwaway290 4y ago
  Yeah, but my server can't tell an impostor either if it fakes my client well enough. Anyway, good point.
sigwinch28 4y ago
"Sign in with X" can and does get abused: https://news.ycombinator.com/item?id=33917962 https://news.ycombinator.com/item?id=33917962 Getting a user to log in on a malicious app which has legitimate OAuth client credentials is usually game over, yes.