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

Torsten Lodderstedt torsten at lodderstedt.net
Fri Jan 8 18:47:24 UTC 2016


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/20160108/5c291404/attachment.html>


More information about the Openid-specs-ab mailing list