<div dir="ltr"><div>Attached below is a diagram outlining the method of using a CLI tool armed with just a refresh token to authenticate to a backend configured as a Relying Party/Client of a particular OIDC IdP.</div><div><br></div><div>The steps are:</div><div><br></div><div>1) The user somehow obtains a refresh token for a particular client (for the moment let's not worry exactly how that happens) and stores that in the configuration for the CLI</div><div><br></div><div>2) The CLI makes request to the backend to exchange a refresh token for an ID Token. </div><div><br></div><div>3) The backend makes the normal OIDC refresh request, sending the refresh token, along with its client_id and client_secret, to the IdP.</div><div><br></div><div>4) The backend server now responds to the request made by the CLI in step #2 with the ID token.</div><div><br></div><div>5) The CLI can now be used to make protected requests to the backend using the ID token. The backend of course validates the ID token on every request, ensuring that it is signed properly, the 'aud' matches its client_id, that the 'sub' is a user known to the backend authorized to perform the desired action, etc. </div><div><br></div><div>If the ID token expires, the CLI will repeat steps 2-4.</div><div><br></div><div>Hope that makes what I'm asking after a bit more clear, and can help determine whether or not this is an appropriate use of refresh tokens.</div><div><br></div><div>Thanks! </div><div><br></div><div>Bobby</div><div><br></div><div><br></div><img src="cid:15246b1b292ad3e48961" alt="refresh.png" class="kr" style="max-width: 100%; opacity: 1;"><br><br><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Jan 11, 2016 at 11:57 AM Bobby Rullo <<a href="mailto:bobby.rullo@coreos.com">bobby.rullo@coreos.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks John and Torsten. Sounds like I need to make a diagram or two....</div><div dir="ltr"><div><br></div><div>Bobby</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jan 11, 2016 at 8:53 AM John Bradley <<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">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><br></div><div>If you are not using a browser with a registered redirect_uri then the client needs to be confidential. </div><div><br></div><div>The documented non http use of OAuth would be SASL <a href="https://tools.ietf.org/html/rfc7628" target="_blank">https://tools.ietf.org/html/rfc7628</a> where OAuth is used to secure IMAP/SMTP.</div><div><br></div><div>Without flow diagrams and much more info I can’t make out what you are proposing for SSH</div><div><br></div><div>Regards</div><div>John B.</div><div><br><div><blockquote type="cite"></blockquote></div></div></div><div style="word-wrap:break-word"><div><div><blockquote type="cite"><div>On Jan 8, 2016, at 1:47 PM, Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net" target="_blank">torsten@lodderstedt.net</a>> wrote:</div><br></blockquote></div></div></div><div style="word-wrap:break-word"><div><div><blockquote type="cite"><div>
<div 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>Am 08.01.2016 um 02:57 schrieb Bobby
Rullo:<br>
</div>
<blockquote 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 href="mailto:torsten@lodderstedt.net" target="_blank">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>
</div></div></blockquote></div></div></div><div style="word-wrap:break-word"><div><div><blockquote type="cite"><div>
_______________________________________________<br>Openid-specs-ab mailing list<br><a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br></div></blockquote></div></div></div></blockquote></div></blockquote></div></div>