<div dir="ltr">Torsten, Thanks for you reply, comments inline:<br><br><div class="gmail_quote"><div dir="ltr">On Fri, Jan 1, 2016 at 8:50 AM Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net">torsten@lodderstedt.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    Hi Bobby,<br>
    <br>
    I think it doesn't make a difference whether a client directly
    exchanges the refresh token for an ID token or whether this request
    is relayed through your server. </div></blockquote><div><br></div><div>To be clear here: the client (in OAuth2 terms) *is* the server. The CLI tool does not have the client secret. Not sure if that changes anything, I just wanted to make sure you were using "client" in the sense of client/server and not in the OAuth sense.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">It just moves the challenge to
    authenticate/identify the client from the OP to your server. How do
    you envision to solve this problem?<br></div></blockquote><div><br></div><div>I was thinking that the server would have an endpoint which, after the typical authorization flow, would publish the refresh token. So a user could access that via the browser, and copy it into a config file for a CLI. Better still would be the CLI tool opening a browser, the user goes through the same authentication process, but the server pushes the token somehow back to the CLI tool after authentication.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
    <br>
    It is generally difficult (if not impossible) to reliably
    authenticate (and authorize) a client on a device (might that be a
    native smartphone app or a CLI tool) towards the OP (or any server).
    You could dynamically create instance specific client_id/client
    secret pairs (Dynamic Client Registration) or you just go with
    public clients (client_id only, no client secret). Note: Neither
    OIDC nor OAuth require a confidential client for the refresh token
    grant type. You may also use public clients in conjunction with this
    grant type. <br></div></blockquote><div><br></div><div>That's why I wanted the Server itself to be the Client, not the CLI tool. If the CLI tool itself is the client, that means one of two things to my understanding - please correct me if I am wrong. Either:</div><div><br></div><div>1) The CLI tool has a client ID and secret which it must protect. Also, this client ID must be somehow registered with my Server as "valid" because when the server validates the ID token, I don't want them to accept any "aud" claim - only ones for that particular client. Having to manage a bunch of clients per Identity on the Server end is a whole new bunch of state to manage.</div><div><br></div><div>2) If I use a so-called public client (just a client_id) then there's any client could get an ID token signed for this public client, and then make requests against my server, which doesn't sound good.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
    <br>
    In either case, you won't have certainty about the identity and
    authorization of the particular caller. It's the user who decides to
    authorize a particular application in the ordinary code flow, which
    in turns provisions the client with a refresh token.</div></blockquote><div> </div><div>In the scenario I outlined, the server is the client, and is able to keep the secret safe. If the user can be trusted to keep their own refresh token secure then it seems everyone's identity is certain, no?</div><div><br></div><div>Thanks again,</div><div><br></div><div>Bobby Rullo</div></div></div>