Creating clients with predefined credentials

[janekolszak]

It would be a nice feature to pass ID/secret pair to hydra clients create.

This is only for development of course. Right now I have to parse .hydra.yml to get the trusted client's credentials. It would be much easier to just have them predefined and hard-coded somewhere.

[aeneasr]

Some values are already possible to pass:

hydra help clients create
This command creates a basic OAuth2 client. Always specify at least one redirect url.

Example:
  hydra clients create -n "my app" -c=[http://localhost/cb] -g [authorization_code] -r [code] -a [core,foobar]

Usage:
  hydra clients create [flags]

Flags:
  -a, --allowed-scopes value   A list of allowed scopes (default [core])
  -c, --callbacks value        REQUIRED list of allowed callback URLs (default [])
  -g, --grant-types value      A list of allowed grant types (default [authorization_code])
      --id string              Give the client this id
  -n, --name string            The client's name
  -r, --response-types value   A list of allowed response types (default [code])

Global Flags:
      --config string     config file (default is $HOME/.hydra.yaml)
      --skip-tls-verify   foolishly accept TLS certificates signed by unkown certificate authorities

it makes sense to pass the password as well. The password should however not be set using --secret=secret but rather by bool flag --secret that prompts for a password

[aeneasr]

Do you need this feature for hydra clients create or for hydra host (the initial admin client credentials)?

[janekolszak]

hydra clients create covers all use cases. I could create the IdP client and possibly some other clients for test purposes (for example the Resource Provider).

But hydra host would be nice as well. There would be only one client for IdP.

[janekolszak]

Please don't make it interactive

[aeneasr]

if it's not interactive, the secret will be stored in bash history, /proc, ..., no?

[aeneasr]

Hm. I took a little time to research and stumbled upon SSH that does not allow to pipe passwords. As already mentioned, passing passwords to the CLI is a security risk. Read more on this:

• http://stackoverflow.com/questions/6607675/shell-script-password-security-of-command-line-parameters
• http://stackoverflow.com/questions/24454037/pass-a-password-to-ssh-in-pure-bash
• http://serverfault.com/questions/592744/how-to-hide-a-password-passed-as-command-line-argument
• http://unix.stackexchange.com/questions/78734/why-shouldnt-someone-use-passwords-in-the-command-line

Really, this should be fixed in the application itself. And such applications should be open source, so that fixing the issue in the app itself should be an option. A security related application which makes this kind of mistake might make other mistakes as well, so I wouldn't trust it.

My best guess right now is setting this through env vars:

USE_SECRET=123456 hydra clients create ...

What do you think @janekolszak ?

[aeneasr]

Check out 9e4e627 - it would work like this:

FORCE_CLIENT_SECRET=somesupersecretPassword hydra create -n "my app" -c=[http://localhost/cb]

[janekolszak]

Command line app has to flush stdin before asking for any security related data, so this option is out.
Passing as an argument will be visible in ps, so it's out.
Environment variable will be visible in .bash_history, also out.

The only option I see is to pass a configuration file with a list of clients to create.

[aeneasr]

Environment variable will be visible in .bash_history, also out.
The only option I see is to pass a configuration file with a list of clients to create.

Isn't this the same? The file can also be read. .bash_history is at least always chmod 700 or owner-/group-read only

[aeneasr]

In container environments secrets are usually set using environment variables. I believe that all PaaS (heroku, cloudfoundry, kubernetes...) don't log environment variables. Unless you think otherwise, I believe this is the right choice.

[janekolszak]

You can set the right permissions for this file too. You can also remove it after your're done with creating clients.

What if I need to create couple of clients?
Env variable would have to be a list.

The configuration and env variable will be on your local laptop anyway. So I guess security isn't that important. Also this feature isn't for production, it's only for debugging and examples. I'd even allow passing the password via command line argument.

[aeneasr]

You're right, it's more obvious if it's a file then a side effect (storing it to .bash_history). Thanks for your thoughts :)

[aeneasr]

@janekolszak I have added this in 69a54e1:

go run main.go clients import
Usage:
  hydra clients import <path/to/file.json> [<path/to/other/file.json>...] [flags]

Flags:
  -h, --help   help for import

Global Flags:
      --config string     config file (default is $HOME/.hydra.yaml)
      --skip-tls-verify   foolishly accept TLS certificates signed by unkown certificate authorities

please let me know if that's what you wanted

[janekolszak]

What's the format of <path/to/file.json> ?

[aeneasr]

The format is the one you send to the HTTP API as documented here

[ashic]

Is there an updated link? The apiary one seems broken.

[aeneasr]

:)