CLI for OAuth 2.0 | Hacker News Reader

CLI for OAuth 2.0

github.com

134 pointsmbilski32 comments

oauth2c is a command-line tool that simplifies the process of experimenting with different grant types and client authentication methods for OAuth 2.0.

something like this would have been useful for working with TripIt and their OAuth1 flow, as getting the right tokens for testing was difficult as hell.

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

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)

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.

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

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.

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.

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

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

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

I think that's what the specs prescribe, yet it seems that desktop clients like VS Code work around that somehow...

A good starting point is 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.

Following their flow at 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).

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

Yeah, but my server can't tell an impostor either if it fakes my client well enough. Anyway, good point.

"Sign in with X" can and does get abused: 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.

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)

PKCE. No client secret needed.

There are multiple clients like this...

oauth2l by Google

step-cli

iddawc

So this can remove the need to use a web browser for authentication of Google API calls?

Depending on the type of flow, probably not:

> Note: To make browser flows work add http://localhost:9876/callback as a redirect URL to your client.

redirect url is required only for authorization code, implicit and hybrid grant flows

How do I do that?

Depends on your oauth provider. If you wish to use the examples from the readme you do not need to anything - they work out of the box

Usually its a 2 part process of 1) whitelisting the callback url in the oauth settings of the provider and 2) passing that whitelisted callback url in the auth flows

Unfortunately Oauth 2.0 is not a standard. It's a toolkit for making standards and pretty much every sufficiently large corporation is going to implement their own unique form. There is no one size fits all solution.

I assume you meant it is not a protocol, which surely is stated in oauth.net [1]. Still it is a pretty much a standard though.

[1]: https://oauth.net/articles/authentication/

Try oacurl.jar

This seems to require a web browser at least for the initial setup.

Actually you can skip it with --no-browser from command line

Specifically for OAuth2 the authentication part for flows that requires redirect, is on the shoulders of the authentication platform. There is no specific API that says how to do it. I can use my user/password to do the login. This is why you have to use a browser if that platform require you to enter the credentials in the browser. Up to that login and from that login, everything is governed by oauth2.

An alternative system, might open the authentication phase in a mobile app or a biometric input, etc... The application at the end of the url will be deciding how to do that.

The reason for the whole thing is that we want to separate the area in which needs protection (authorization) and the area which does the authentication and can sit at a trusted site and may supply services to several resource servers.

You can play with such an implementation with an open source keycloak server. It really clearly reveals how the whole thing works.

Reply on news.ycombinator.com