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

Bobby Rullo bobby.rullo at coreos.com
Fri Jan 8 20:49:20 UTC 2016


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>
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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20160108/f4719caf/attachment-0001.html>


More information about the Openid-specs-ab mailing list