Add scopes to OIDC configuration

[jeremydonahue]

This allows the CLI to retrieve custom scopes from the provider for use when performing the oauth exchange to generate a token. Custom scopes are useful, for example, when using the OIDC provider with Dex and Github in that it allows the preferred_username or federated_claims.user_id fields to be returned with the token for use in SSH certificate templates (ie. to identify a Github user via extensions:login@github.com).

Example usage:
ca.json:

{
    "type": "OIDC",
    ...
    "scopes": ["openid","email","profile","federated:id"]
}

SSH template:

	"extensions": {
	  "id@github.com": {{ toJson .Token.federated_claims.user_id }}
	}

This will be followed up with a corresponding PR for smallstep/cli that makes use of the feature... update: smallstep/cli#1150

Name of feature:

Custom scopes for OIDC providers.

Pain or issue this feature alleviates:

The inability to use step-ca for generating ssh certificates for github when using Dex as an OIDC provider (Dex is configured to use the Github connector).

Why is this important to the project (if not answered above):

Answered above.

Is there documentation on how to use this feature? If so, where?

No, because I could not find where to update https://smallstep.com/docs/step-ca. If you point me in the right direction, I will happily update the docs.

In what environments or workflows is this feature supported?

OIDC providers.

In what environments or workflows is this feature explicitly NOT supported (if any)?

Non-OIDC providers.

Supporting links/other PRs/issues:

PR that makes use of the feature in the step CLI: smallstep/cli#1150

[CLAassistant]

All committers have signed the CLA.

[jeremydonahue]

Oh, one more note, I saw that the contributing guidelines say there should be an addition to the changelog, which I am happy to do, but I wasn't sure how to do that given that I imagine multiple features/bugfixes/etc will be included in one release.

[maraino]

Hi @jeremydonahue,

We will accept your contribution, but this PR and smallstep/cli#1150 are not complete, as they do not allow the configuration of the provisioners using a database or a linked CA.

Right now, I can think of:

• New field in https://github.com/smallstep/linkedca/blob/d564a7aef39f20eeaaac2531fe736f23f2798a84/spec/linkedca/provisioners.proto#L101-L110
• New fields in
  

  certificates/authority/provisioners.go

  Line 823 in 725a913

  func ProvisionerToCertificates(p *linkedca.Provisioner) (provisioner.Interface, error) {

  and
  

  certificates/authority/provisioners.go

  Line 1021 in 725a913

  func ProvisionerToLinkedca(p provisioner.Interface) (*linkedca.Provisioner, error) {

• And on the cli side, support in step ca provisioner add and step ca provisioner update.

We can work on the rest of the updates, but it might take some time. Or you can work on a more complete version.

As a current workaround, you can edit the $(step path)/config/defaults.json on the client side and add the scopes there as this:

{
  "...": "...",
  "scope": ["openid","email","profile","federated:id"]
}

[jeremydonahue]

@maraino Hi, thanks for your response, and sorry for the delay (I was on vacation). I'm happy to update this to be more complete. However, I see that @jdoupe has already done so in their set of PRs. Would you still like me to do so here, or is that sufficient? Disclaimer: I have not reviewed their PRs closely.

[maraino]

@jeremydonahue I've seen that @jdoupe has added your contribution too, but I haven't had time to review them yet.

[jdoupe]

@jeremydonahue - Sorry to have coopted your change. I'm not sure why I hadn't really thought to include that in my original thought anyway (I actually do, but long story ;) ), but definitely seemed like the "thing to do" since I was updating all the same pieces anyway.