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

[Torsten Lodderstedt]

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. It just moves the challenge to 
authenticate/identify the client from the OP to your server. How do you 
envision to solve this problem?

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.

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.

For more details, you may take a look into 
https://tools.ietf.org/html/rfc6749#section-10.1 and 
https://tools.ietf.org/html/rfc6819#section-4.1.

best regards,
Torsten.

Am 22.12.2015 um 02:54 schrieb Bobby Rullo:
> Hi there,
>
> 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.
>
> 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)
>
> 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.
>
> 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.
>
> 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.
>
> Thank you,
>
> Bobby Rullo
> CoreOS
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20160101/b58ff230/attachment.html>