Open tmcolby opened 4 years ago
Similarly step ca token <subject> --issuer <some oidc provisioner>
should accept the --console
argument. I suppose, more generically, anywhere you select an oidc provisioner one should be able to not leave the shell by passing the argument.
If you cal step oauth
without any other arguments it uses client_id=1087160488420-8qt7bavg3qesdhs6it824mhnfgcfe8il.apps.googleusercontent.com
which is owned by smallstep. Is this a bug/error? For the sake of generic and opensource, shouldn't the command consult my CA at --ca-url for a default oath url instead of hitting a smallstep owned provisioner?
Yea, the step ssh login
and step ca token
(and step ca certificate
) commands run step oauth
if you're using an OAuth OIDC provisioner. We should probably add the --console
flag to these commands. Initially I was going to ask why you wouldn't just run step ssh login ... --token $(step oauth --console ...)
, but then I realized there's no easy way to get the OAuth configuration details from the CA down to the step oauth
command. So I guess this is needed.
If you cal step oauth without any other arguments it uses
client_id=1087160488420-8qt7bavg3qesdhs6it824mhnfgcfe8il.apps.googleusercontent.com
which is owned by smallstep. Is this a bug/error?
This is by design. This client is scoped such that the OAuth access token can't be used for anything. The OIDC identity token is audience-addressed and the callback is set to 127.0.0.1
. So the only way to get a token using this client is to be running locally on a machine. It's subtle, and it's been a while since we threat modeled this, but the flow has essentially the same security characteristics as any other OAuth flow.
The advantage, then, is that you can safely use this client for authenticating using G Suite + OIDC without having to go through the process of creating your own. So it's a simple expediency for some use cases.
For reference, this is following BCP for OAuth 2.0 Native Apps. It's also the same thing that Google's gcloud
command-line tool does. So it's pretty standard and there's reputable prior art.
For the sake of generic and opensource, shouldn't the command consult my CA at --ca-url for a default oath url instead of hitting a smallstep owned provisioner?
Maybe, but step
in general doesn't require that you have a CA running. In particular, step oauth
doesn't need a CA. This could be a nice feature to add to step oauth
, however, and it could solve the problem from above without requiring the --console
flag on other subcommands... would that work for you?
Hi, Mike, thanks for your feedback. Yes, this:
but then I realized there's no easy way to get the OAuth configuration details from the CA down to the step oauth command.
Short of scraping step ca provisioner list
, there is no easy way at the moment.
Either the above, or adding --console
on the other subcommands could solve for the issue. My preference, for sake of a straightforward workflow and simplicity (in my opinion), would be to have the ability to run step ssh login ... --console
. Otherwise, for my use case, I will need to create a custom login script or alias to achieve the same thing. It would be nice and tidy if step-cli did this out of the box though. I imagine as the project grows, eventually, both approaches will get solved for ;)
-Thanks, Tyson Colby
Hi @tmcolby, we are going to add the --console
flag, but there's a trick that you can use right now. If you set the environment variable STEP_CONSOLE=true
it will force --console
to be set:
STEP_CONSOLE=true step ssh login jane@doe.com
Great.. thanks for the hack @maraino . I just tried this and it works as you stated.
What would you like to be added
The
step oath
command can be called with--console
when headless. It would be useful to be able to pass this argument when doingstep ssh login <user> --issuer <some oidc provisioner>
Why this is needed
I could be mistaken, but I think the
step ssh login ..
automates the oauth flow. For example, I can doto achieve what I want when working on a headless host. We should be able to pass the
--console
argument tostep ssh login ..
to achieve the same result