[HN Gopher] CLI for OAuth 2.0
       ___________________________________________________________________
        
       CLI for OAuth 2.0
        
       Author : mbilski
       Score  : 115 points
       Date   : 2022-12-09 13:16 UTC (9 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | shrx wrote:
       | So this can remove the need to use a web browser for
       | authentication of Google API calls?
        
         | mobilio wrote:
         | Try oacurl.jar
        
           | shrx wrote:
           | This seems to require a web browser at least for the initial
           | setup.
        
             | mobilio wrote:
             | Actually you can skip it with --no-browser from command
             | line
        
         | vladvasiliu wrote:
         | 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.
        
           | kohlerm wrote:
           | How do I do that?
        
             | JamesSwift wrote:
             | 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
        
             | mbilski wrote:
             | 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
        
             | superkuh wrote:
             | 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.
        
           | mbilski wrote:
           | redirect url is required only for authorization code,
           | implicit and hybrid grant flows
        
         | tzahifadida wrote:
         | 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.
        
       | mbilski wrote:
       | oauth2c is a command-line tool that simplifies the process of
       | experimenting with different grant types and client
       | authentication methods for OAuth 2.0.
        
       | encryptluks2 wrote:
       | There are multiple clients like this...
       | 
       | oauth2l by Google
       | 
       | step-cli
       | 
       | iddawc
        
       | throwaway290 wrote:
       | Tangentially, anyone knows how to securely implement OAuth2 in a
       | native client (like a desktop app)? How to deal with client
       | secret?
        
         | nightpool wrote:
         | 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)
        
         | sigwinch28 wrote:
         | 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.
        
       | nunez wrote:
       | 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.
        
       ___________________________________________________________________
       (page generated 2022-12-09 23:01 UTC)