How to configure OIDC on different authorization servers

[maraino]

Description

Add docs on how to configure an OIDC provisioner on different OAuth 2.0/OpenID Connect providers:

• Google
• Microsoft
• Okta
• Auth0
• Keycloak
• ...

Add to https://smallstep.com/docs/step-ca/integrations#oidc

[mannp]

Any possibility of keycloak being added here too please? :+1:

[logopk]

Reminder: Based on discussions on Gitter, GitLab as OIDC provisioner fails as they a) do not provide email-address in token (leading to "token is not supported"), b) are non-compliant on dynamic port redirectURI (workaround would be "listenAddress": "127.0.0.1:12345" in ca-config) and do not support --console mode "urn:ietf:wg:oauth:2.0:oob" is no acceptable redirectURI.

[joshathysolate]

Question for you guys - I'm trying to figure out how to properly configure Azure AD for OIDC authentication and am almost there but I get back the following error:

Failed exchanging authorization code: json: cannot unmarshal string into Go struct field token.expires_in of type int error running: step oauth --oidc --bare --provider https://login.microsoftonline.com/hysolatese.onmicrosoft.com/.well-known/openid-configuration --client-id REMOVED --client-secret REMOVED --listen localhost:6001: exit status 1

Any idea what I may be missing on the Microsoft side of the configuration?

[mmalone]

That's weird. Quick context, a successful OAuth Access Token response looks like:

    HTTP/1.1 200 OK
     Content-Type: application/json;charset=UTF-8
     Cache-Control: no-store
     Pragma: no-cache

     {
       "access_token":"2YotnFZFEjr1zCsicMWpAA",
       "token_type":"example",
       "expires_in":3600,
       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
       "example_parameter":"example_value"
     }

The error message looks suspiciously like Azure AD is sending the expires_in parameter as a string instead of an int. This would be a spec violation, so that'd be a bug on their side, if true. We've never encountered this error before, and we've tested extensively with Azure AD, so I think this would be a regression (unless you've done something unusual with your configuration that is forcing this to be a string, which I'm assuming is not the case).

[joshathysolate]

Do you happen to have any basic instructions on how you've configured Azure AD? It could very well be a config setting on my end b/c it's the first time I've tried setting up OIDC with Azure.

[maraino]

@joshathysolate Here some basic instructions:

1. Using the azure cli run:

   az ad app create --display-name "Your Application Name" --reply-urls http://127.0.0.1

   You can also do this in the UI on Azure Active Directory -> App Registration -> New registration, but then you will need to use http://localhost and some extra configuration in the CA, he UI doesn't allow you to use 127.0.0.1 that is the value recommended by the standard.

2. Look for the Application and get:

   • Application (Client) Id
   • OpenID Connect metadata document on the 'Endpoints' tab

3. Create a secret using the 'Certificates & secret' section of the app.

4. Finally, you can create the provisioner in the ca.json, it will look something like:

   {
   "type": "OIDC",
   "name": "Azure AD - My Provisioner name",
   "clientID": "<client-id>",
   "clientSecret": "<client-secret>",
   "configurationEndpoint": "https://login.microsoftonline.com/<tenant-id>/v2.0/.well-known/openid-configuration"
   }

If you end up using the UI, you might need to add "listenAddress": "localhost:0" to make it work. And you allow multiple domains you can also allow only some using "domains": ["okdomain.com"]

[maraino]

Using the above instructions I'm also able to run without specifying the --listen address:

step oauth --oidc --bare --provider https://login.microsoftonline.com/<tenant-id>/v2.0/.well-known/openid-configuration --client-id <client-id> --client-secret <client-secret>

and get the OIDC token.

[joshathysolate]

Great - it looks close to what I did but I will kill my existing app registration and give this a try instead. Thanks @maraino!

[joshathysolate]

FYI - it looks like I was using the older configuration endpoint as I was missing the v2.0 in the URL.

[etudurd]

Hello, I am trying for 2 weeks to implement SSO via keycloak+smallstep to remotely access some ssh servers, but without success. There are any options / implemented solutions available (to take them as example)? Many thanks!

[tashian]

Hi @etudurd, one good example is our DIY SSO for SSH blog post, which will take you through the entire SSH setup, using a Google Cloud OAuth client.

While we don't have a specific Keycloak example, the OIDC provisioner for step-ca only needs three parameters:

• The OIDC well-known configuration endpoint: This is the OpenID JSON discovery document, usually a URL that end in /.well-known/openid-configuration). Configure this endpoint in your Keycloak realm. (Here's an example.)
• Client Credentials: the Client ID and the Client Secret, which you'll configure in Keycloak.

You may also need to change the listenAddress — which is the port number used by the OAuth redirect URL (eg. 'http://127.0.0.1:10000'). It defaults to using a random port for the redirect.

Hope this helps!