[Openid-specs-ab] Command line user agents & Refresh Tokens
bobby.rullo at coreos.com
Tue Dec 22 01:54:14 UTC 2015
I am working on a project which uses OpenID Connect (OIDC) for
authentication. We have a Server which serves API requests; it plays the
role of the Relying Party (RP) in this scenario - end-users get
authenticated via the OIDC authorization flow, and they hold onto their
(short-lived) ID Token which they pass to the Server on requests, and the
Server validates in the usual OIDC way.
This flow works ok when there is a browser involved, but the main way in
which users interact with the Server is through a command line client, and
browsers may not be available (eg. they are SSH'd into some machine)
Indeed, the user might not even be present (eg. cron jobs)
The thing that immediately springs to mind is refresh tokens: ideally, the
CLI tool would hold on to a long-lived refresh token, which it would
exchange for short lived ID tokens. However, the way OIDC works is that the
agent doing the exchange must have both the Client ID and the Client Secret
to perform the exchange.
We certainly don't want to give everyone who needs to access the Server its
Secret, so we could have an endpoint on our Server which takes a Refresh
Token and does the exchange with the IdP for the ID token and passes it
back to the CLI tool. This seems fine to me, but a collaborator expressed
concern that it's just bypassing OIDC's exchange process which requires a
client id and secret. I disagree, because even in this scenario no one can
mint a new ID token without the Server being involved.
So what is the "right" way to implement CLI tools that need to have
long-lived tokens with OIDC? I haven't found much written about it, so I'm
bringing it up here.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab