5 ms·

CLI for OAuth 2.0

134 points by mbilski 4y ago

mbilski 4y ago
oauth2c is a command-line tool that simplifies the process of experimenting with different grant types and client authentication methods for OAuth 2.0.
shrx 4y ago
So this can remove the need to use a web browser for authentication of Google API calls?
- vladvasiliu 4y ago
  Depending on the type of flow, probably not: > Note: To make browser flows work add http://localhost:9876/callback http://localhost:9876/callback as a redirect URL to your client.
  - mbilski 4y ago
    redirect url is required only for authorization code, implicit and hybrid grant flows
  - kohlerm 4y ago
    How do I do that?
    - mbilski 4y ago
      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
    - JamesSwift 4y ago
      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
    - superkuh 4y ago
      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.
      - tnzk 4y ago
        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/ https://oauth.net/articles/authentication/
- mobilio 4y ago
  Try oacurl.jar
  - shrx 4y ago
    This seems to require a web browser at least for the initial setup.
    - mobilio 4y ago
      Actually you can skip it with --no-browser from command line
- tzahifadida 4y ago
  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.
nunez 4y ago
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.
throwaway290 4y ago
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.
encryptluks2 4y ago
There are multiple clients like this... oauth2l by Google step-cli iddawc

134 points by mbilski 4y ago

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

shrx 4y ago

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

vladvasiliu 4y ago
Depending on the type of flow, probably not: > Note: To make browser flows work add http://localhost:9876/callback http://localhost:9876/callback as a redirect URL to your client.
- mbilski 4y ago
  redirect url is required only for authorization code, implicit and hybrid grant flows
- kohlerm 4y ago
  How do I do that?
  - mbilski 4y ago
    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
  - JamesSwift 4y ago
    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
  - superkuh 4y ago
    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.
    - tnzk 4y ago
      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/ https://oauth.net/articles/authentication/
mobilio 4y ago
Try oacurl.jar
- shrx 4y ago
  This seems to require a web browser at least for the initial setup.
  - mobilio 4y ago
    Actually you can skip it with --no-browser from command line
tzahifadida 4y ago
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.

nunez 4y ago

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.

throwaway290 4y ago

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.

encryptluks2 4y ago

There are multiple clients like this... oauth2l by Google step-cli iddawc