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

[Bobby Rullo]

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/20160111/924f8746/attachment.html>