Add support for the client_credentials flow?

[aldbr]

Hello,

IIUC, the oidc-gen command generates an OAuth2 client and starts an authorization_code (or password, or device_code) flow requiring user interaction.
Once done, the refresh token is securely stored and can be used by the oidc-token command (refresh_token flow).

This workflow is fine for scenarios requiring user interaction, but what about machine-to-machine communications?
Are you planning to integrate the client_credentials flow in oidc-agent?
Or do you think this use case should be manually handled since there is no need to store a refresh token?

Thanks

[aldbr]

Hello,

Any news about this?
Thanks

[zachmann]

I'm sorry for the delayed response.

It is indeed a good question. We didn't implement this yet because we had personal usage of oidc-agent in mind.

The flow is rather simple and could also be handled by a simple script, so I'm a bit unsure about the benefit to have this in the agent.
There could be a benefit with regards to encrypted client credentials, but in a m2m context there must be the option to decrypt it without user interaction, so that is also not really a strong plus.

What do you think, would it be beneficial to have this in the agent instead of a simple script?

[maarten-litmaath]

Hallo Gabriel,
might you provide an example script to demonstrate how simple it should be?

[aldbr]

There could be a benefit with regards to encrypted client credentials

Indeed, I was mainly thinking about this.

What do you think, would it be beneficial to have this in the agent instead of a simple script?

In my humble opinion, a simple script should be enough.

To be honest, I created this discussion for the following reason: we are using the client_credentials flow to perform a specific operation (thus without using oidc-agent).
Another team needs to perform the same operation but they heavily rely on oidc-agent, and thus we have 3 possible solutions:

• we provide them with an oidc-agent configuration so that they can use our user refresh token to get an access token.
• they modify their code to use the client_credentials flow with a simple script instead of relying on oidc-agent.
• you allow oidc-agent to support the client_credentials flow.

Option1 or 2 seem to be easier to set up than option3.

might you provide an example script to demonstrate how simple it should be?

I guess the following script could work, what do you think @zachmann @maarten-litmaath?

#!/bin/bash

# ---------------------------------------------------
# inputs
# ---------------------------------------------------

# Issuer URL
# Could be passed in parameter as $1
ISSUER_URL="https://example.com/"

# Token Endpoint
# Could be extracted from the .well-known path or passed in parameter as $2 (or as part of ISSUER_URL in $1)
# Should be present in $ISSUER_URL/.well-known/openid-configuration 
TOKEN_ENDPOINT="${ISSUER_URL}/oauth2/token"

# Client credentials
# Could be extracted from a secret management service (e.g. teigi)
CLIENT_ID="your_client_id"
CLIENT_SECRET="your_client_secret"

# ---------------------------------------------------
# get a client access token
# ---------------------------------------------------

# Request an access token
response=$(curl -s \
  -u ${CLIENT_ID}:${CLIENT_SECRET} \
  -d "grant_type=client_credentials" \
  ${TOKEN_ENDPOINT})

# Extract the access token from the response
access_token=$(echo $response | jq -r '.access_token')

# ---------------------------------------------------
# use the client access token
# ---------------------------------------------------
...

[zachmann]

I came up with a similiar script:

# Use ISS, CLIENT_ID, CLIENT_SECRET from env vars or command line arguments
ISS="${ISS:-$1}"
CLIENT_ID="${CLIENT_ID:-$1}"
CLIENT_SECRET="${CLIENT_SECRET:-$3}"

# Obtain token endpoint
TOKEN_ENDPOINT=$(curl $ISS/.well-known/openid-configuration 2>/dev/null | jq -r .token_endpoint)
# Client credentials flow
curl $TOKEN_ENDPOINT -u $CLIENT_ID:$CLIENT_SECRET -d 'grant_type=client_credentials' 2>/dev/null | jq -r .access_token

[zachmann]

We can add this to the agent; so it's not a problem of implementation complexity. My main concern is if it makes sense. But it there is interest, we can support this.

I see two options how this then could be used with the agent:

1. Without creating an account configuration. This is basically the same as a script solution would be, but instead of a custom script it uses oidc-agent. The following calls then should each give an access token:

 oidc-gen --flow=client --client_id=<client_id> --client_secret=<client_secret> --only-at
 oidc-gen --flow=client -f/path/to/file/with/client-credentials --only-at

2. Create an account config with oidc-gen and then use it normally with oidc-token or other clients:

oidc-gen --flow=client <shortname>
oidc-token <shortname>

Approach 2 would create an encrypted account configuration. Encryption is a plus, but might bring problems in machine2machine usability.
The following options exist:

• manually load with encryption password
• use pw-file
• use gpg encryption

Of course using an encryption mechanism that can be done non-interactively will only give limited encryption benefits.

[aldbr]

We eventually provide them with an oidc-agent configuration because it was the simplest solution for everyone.
But thanks a lot for the details!