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

[John Bradley]

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 <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 <mailto: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/c09d5a1f/attachment.html>