<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body 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. 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>
<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>
<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. In the end, the
refresh token functions as a instance specific secret, which is
dynamically provisioned and represents the authorization to act on
behalf of the user. If you replace the refresh token with every
refresh request, you may also detect replay.<br>
<br>
For more details, you may take a look into
<a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/rfc6749#section-10.1">https://tools.ietf.org/html/rfc6749#section-10.1</a> and
<a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/rfc6819#section-4.1">https://tools.ietf.org/html/rfc6819#section-4.1</a>.<br>
<br>
best regards,<br>
Torsten.<br>
<br>
<div class="moz-cite-prefix">Am 22.12.2015 um 02:54 schrieb Bobby
Rullo:<br>
</div>
<blockquote
cite="mid:CANFpDABVZSxcHaZYWMcUNFsOO8BgB-1dMJ-cC4otGwmexqoG+Q@mail.gmail.com"
type="cite">
<div dir="ltr">Hi there,
<div><br>
</div>
<div>I am working on a project which uses OpenID Connect (OIDC)
for authentication. We have a Server which serves API
requests; it plays the role of the Relying Party (RP) in this
scenario - end-users get authenticated via the OIDC
authorization flow, and they hold onto their (short-lived) ID
Token which they pass to the Server on requests, and the
Server validates in the usual OIDC way.</div>
<div><br>
</div>
<div>This flow works ok when there is a browser involved, but
the main way in which users interact with the Server is
through a command line client, and browsers may not be
available (eg. they are SSH'd into some machine) Indeed, the
user might not even be present (eg. cron jobs) </div>
<div><br>
</div>
<div>The thing that immediately springs to mind is refresh
tokens: ideally, the CLI tool would hold on to a long-lived
refresh token, which it would exchange for short lived ID
tokens. However, the way OIDC works is that the agent doing
the exchange must have both the Client ID and the Client
Secret to perform the exchange. </div>
<div><br>
</div>
<div>We certainly don't want to give everyone who needs to
access the Server its Secret, so we could have an endpoint on
our Server which takes a Refresh Token and does the exchange
with the IdP for the ID token and passes it back to the CLI
tool. This seems fine to me, but a collaborator expressed
concern that it's just bypassing OIDC's exchange process which
requires a client id and secret. I disagree, because even in
this scenario no one can mint a new ID token without the
Server being involved. </div>
<div><br>
</div>
<div>So what is the "right" way to implement CLI tools that need
to have long-lived tokens with OIDC? I haven't found much
written about it, so I'm bringing it up here.</div>
<div><br>
</div>
<div>Thank you,</div>
<div><br>
</div>
<div>Bobby Rullo</div>
<div>CoreOS</div>
<div><br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Openid-specs-ab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
<br>
</body>
</html>