<div dir="ltr">Hi there, <div><br></div><div>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.</div><div><br></div><div>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) </div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>Thank you,</div><div><br></div><div>Bobby Rullo</div><div>CoreOS</div><div><br></div></div>