[Openid-specs-ab] Command line user agents & Refresh Tokens

Bobby Rullo bobby.rullo at coreos.com
Fri Jan 8 01:57:46 UTC 2016


Torsten, Thanks for you reply, comments inline:

On Fri, Jan 1, 2016 at 8:50 AM Torsten Lodderstedt <torsten at lodderstedt.net>
wrote:

> Hi Bobby,
>
> 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.
>

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.


> It just moves the challenge to authenticate/identify the client from the
> OP to your server. How do you envision to solve this problem?
>

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.


>
> 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.
>

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:

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.

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.


>
> 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 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?

Thanks again,

Bobby Rullo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20160108/cfa28a88/attachment.html>


More information about the Openid-specs-ab mailing list