<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Bobby,<br>
<br>
I don't think we will make any progress on the basis of the
information provided so far. If you want reasonable advice, please
describe the solution you have in mind in more detail (components,
message flows).<br>
<br>
best regards,<br>
Torsten.<br>
<br>
<div class="moz-cite-prefix">Am 08.01.2016 um 21:49 schrieb Bobby
Rullo:<br>
</div>
<blockquote
cite="mid:CANFpDAAttgt+jAomkWAFVe_n5esFCWg6vceg6Rv5M+uQgzQ+Ag@mail.gmail.com"
type="cite">
<div dir="ltr">This confuses me a bit. Here's the scenario I am
worried about:
<div><br>
</div>
<div>Imagine there's a well known OIDC IdP out here, like
Google. I decide to use Google as the IdP for my application
(called GoodApp), so I create a client, get a client ID and
secret for that app. </div>
<div><br>
</div>
<div>Now some malicious person creates a client (BadApp) as
well, and makes it sufficiently interesting so that someone
who is a user of GoodApp decides to use, and authenticates
against it. If GoodApp is not guarding their secret well, then
BadApp would be able to mint a refresh token for GoodApp when
the unsuspecting user goes through the BadApp flow, right?</div>
<div><br>
</div>
<div>Thanks again,</div>
<div>Bobby</div>
<div dir="ltr">
<div>
<div><br>
<div class="gmail_quote">
<div dir="ltr">On Fri, Jan 8, 2016 at 10:47 AM Torsten
Lodderstedt <<a moz-do-not-send="true"
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>
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>
</div>
<div text="#000000" bgcolor="#FFFFFF"> <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
moz-do-not-send="true"
href="mailto:torsten@lodderstedt.net"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:torsten@lodderstedt.net">torsten@lodderstedt.net</a></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>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>