<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">OAuth 2 is intended to work with a confidential client that has a unique and protected secret, or via a unique registered redirect_uri in the case of a public client.<div class=""><br class=""></div><div class="">If you are not using a browser with a registered redirect_uri then the client needs to be confidential. </div><div class=""><br class=""></div><div class="">The documented non http use of OAuth would be SASL <a href="https://tools.ietf.org/html/rfc7628" class="">https://tools.ietf.org/html/rfc7628</a> where OAuth is used to secure IMAP/SMTP.</div><div class=""><br class=""></div><div class="">Without flow diagrams and much more info I can’t make out what you are proposing for SSH</div><div class=""><br class=""></div><div class="">Regards</div><div class="">John B.</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 8, 2016, at 1:47 PM, Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net" class="">torsten@lodderstedt.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
Hi Bobby,<br class="">
<br class="">
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 class="">
<br class="">
best regards,<br class="">
Torsten. <br class="">
<br class="">
<div class="moz-cite-prefix">Am 08.01.2016 um 02:57 schrieb Bobby
Rullo:<br class="">
</div>
<blockquote cite="mid:CANFpDAB0M2dqEP4hCxn7LYFQmg=A6UXqG13MEEWA1d03_V6uWg@mail.gmail.com" type="cite" class="">
<div dir="ltr" class="">Torsten, Thanks for you reply, comments inline:<br class="">
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="">On Fri, Jan 1, 2016 at 8:50 AM Torsten
Lodderstedt <<a moz-do-not-send="true" href="mailto:torsten@lodderstedt.net" class="">torsten@lodderstedt.net</a>>
wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF" class=""> Hi Bobby,<br class="">
<br class="">
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 class=""><br class="">
</div>
<div class="">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 class=""> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF" class="">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 class="">
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">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 class=""> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF" class=""> <br class="">
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 class="">
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">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 class=""><br class="">
</div>
<div class="">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 class=""><br class="">
</div>
<div class="">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 class=""> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF" class=""> <br class="">
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 class=""> </div>
<div class="">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 class=""><br class="">
</div>
<div class="">Thanks again,</div>
<div class=""><br class="">
</div>
<div class="">Bobby Rullo</div>
</div>
</div>
</blockquote>
<br class="">
</div>
_______________________________________________<br class="">Openid-specs-ab mailing list<br class=""><a href="mailto:Openid-specs-ab@lists.openid.net" class="">Openid-specs-ab@lists.openid.net</a><br class="">http://lists.openid.net/mailman/listinfo/openid-specs-ab<br class=""></div></blockquote></div><br class=""></div></body></html>