<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Bobby,<br>
<br>
let me re-state my message: I does not matter whether your server
(as the OAuth client) can keep the client secret secret. Why? It
does not make a difference from a security perspective if a CLI
client access a service via this server or directly since the CLI
client is not authenticated in both cases. So I can write an
alternative client and access your server as well. That's not bad,
that's just a fact. The security of the overall solution depends on
the confidentiality of the refresh token, which can work for both
options equally.<br>
<br>
best regards,<br>
Torsten. <br>
<br>
<div class="moz-cite-prefix">Am 08.01.2016 um 02:57 schrieb Bobby
Rullo:<br>
</div>
<blockquote
cite="mid:CANFpDAB0M2dqEP4hCxn7LYFQmg=A6UXqG13MEEWA1d03_V6uWg@mail.gmail.com"
type="cite">
<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 moz-do-not-send="true"
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>
</blockquote>
<br>
</body>
</html>