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

[Torsten Lodderstedt]

Hi Bobby,

I don't think we will make any progress on the basis of the information 
provided so far. If you want reasonable advice, please describe the 
solution you have in mind in more detail (components, message flows).

best regards,
Torsten.

Am 08.01.2016 um 21:49 schrieb Bobby Rullo:
> This confuses me a bit. Here's the scenario I am worried about:
>
> Imagine there's a well known OIDC IdP out here, like Google. I decide 
> to use Google as the IdP for my application (called GoodApp), so I 
> create a client, get a client ID and secret for that app.
>
> Now some malicious person creates a client (BadApp) as well, and makes 
> it sufficiently interesting so that someone who is a user of GoodApp 
> decides to use, and authenticates against it. If GoodApp is not 
> guarding their secret well, then BadApp would be able to mint a 
> refresh token for GoodApp when the unsuspecting user goes through the 
> BadApp flow, right?
>
> Thanks again,
> Bobby
>
> On Fri, Jan 8, 2016 at 10:47 AM Torsten Lodderstedt 
> <torsten at lodderstedt.net <mailto: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
>

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