[Openid-specs-ab] Command line user agents & Refresh Tokens
torsten at lodderstedt.net
Fri Jan 8 18:47:24 UTC 2016
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.
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...
More information about the Openid-specs-ab