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

[Bobby Rullo]

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.

The steps are:

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

2) The CLI makes request to the backend to exchange a refresh token for an
ID Token.

3) The backend makes the normal OIDC refresh request, sending the refresh
token, along with its client_id and client_secret, to the IdP.

4) The backend server now responds to the request made by the CLI in step
#2 with the ID token.

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.

If the ID token expires, the CLI will repeat steps 2-4.

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.

Thanks!

Bobby


[image: refresh.png]



On Mon, Jan 11, 2016 at 11:57 AM Bobby Rullo <bobby.rullo at coreos.com> wrote:

> Thanks John and Torsten. Sounds like I need to make a diagram or two....
>
> Bobby
>
> On Mon, Jan 11, 2016 at 8:53 AM John Bradley <ve7jtb at ve7jtb.com> wrote:
>
>> 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.
>>
>> If you are not using a browser with a registered redirect_uri then the
>> client needs to be confidential.
>>
>> The documented non http use of OAuth would be SASL
>> https://tools.ietf.org/html/rfc7628  where OAuth is used to secure
>> IMAP/SMTP.
>>
>> Without flow diagrams and much more info I can’t make out what you are
>> proposing for SSH
>>
>> Regards
>> John B.
>>
>> On Jan 8, 2016, at 1:47 PM, Torsten Lodderstedt <torsten at lodderstedt.net>
>> wrote:
>>
>> Hi Bobby,
>>
>> 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.
>>
>> best regards,
>> Torsten.
>>
>> Am 08.01.2016 um 02:57 schrieb Bobby Rullo:
>>
>> 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
>>
>>
>> _______________________________________________
>> 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/20160115/5f3c8085/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refresh.png
Type: image/png
Size: 18236 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20160115/5f3c8085/attachment.png>