You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The step oath command can be called with --console when headless. It would be useful to be able to pass this argument when doing step 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 do
to achieve what I want when working on a headless host. We should be able to pass the --console argument to step ssh login .. to achieve the same result
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?
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 ;)
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:
Activity
[-]add headless support to [step ssh login ..][/-][+]add headless support to `step ssh login ..`[/+][-]add headless support to `step ssh login ..`[/-][+]add headless support to [step ssh login ..][/+]tmcolby commentedon May 27, 2020
Similarly
step ca token <subject> --issuer <some oidc provisioner>should accept the--consoleargument. I suppose, more generically, anywhere you select an oidc provisioner one should be able to not leave the shell by passing the argument.tmcolby commentedon May 27, 2020
If you cal
step oauthwithout any other arguments it usesclient_id=1087160488420-8qt7bavg3qesdhs6it824mhnfgcfe8il.apps.googleusercontent.comwhich 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?mmalone commentedon May 27, 2020
Yea, the
step ssh loginandstep ca token(andstep ca certificate) commands runstep oauthif you're using an OAuth OIDC provisioner. We should probably add the--consoleflag to these commands. Initially I was going to ask why you wouldn't just runstep 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 thestep oauthcommand. So I guess this is needed.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
gcloudcommand-line tool does. So it's pretty standard and there's reputable prior art.Maybe, but
stepin general doesn't require that you have a CA running. In particular,step oauthdoesn't need a CA. This could be a nice feature to add tostep oauth, however, and it could solve the problem from above without requiring the--consoleflag on other subcommands... would that work for you?tmcolby commentedon May 28, 2020
Hi, Mike, thanks for your feedback. Yes, this:
Short of scraping
step ca provisioner list, there is no easy way at the moment.Either the above, or adding
--consoleon 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 runstep 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
maraino commentedon Jun 23, 2020
Hi @tmcolby, we are going to add the
--consoleflag, but there's a trick that you can use right now. If you set the environment variableSTEP_CONSOLE=trueit will force--consoleto be set:tmcolby commentedon Jun 30, 2020
Great.. thanks for the hack @maraino . I just tried this and it works as you stated.