feat(http): add oauth2 client_credentials support

[ozozgun]

This PR provides built-in support for OAuth2 client credentials flow authentication. This allows you to set up authenticated API calls in your tests.

Setting up OAuth2 Authentication

Use the Setup authentication step to configure OAuth2 client credentials. This will automatically fetch the access token from the specified token URL:

Background:
  * Setup authentication for clientId "my-service" with clientSecret "secret123" and token url "http://auth-server/oauth/token"

This step will:

1. Make a POST request to the token URL with grant_type=client_credentials
2. Parse the access_token from the JSON response
3. Cache the token for use in subsequent authenticated calls

Making Authenticated HTTP Calls

Once authentication is set up, you can make authenticated HTTP calls using the as authenticated user syntax:

# Simple GET request
When we call "http://backend/api/resource" as authenticated user "my-service"

# POST with body
When we post on "http://backend/api/users" as authenticated user "my-service" with:
  """json
  {
    "name": "John Doe"
  }
  """

The authenticated calls will automatically include the Authorization: Bearer <token> header.

[CLAassistant]

All committers have signed the CLA.

[alexandrepa]

First, thanks for this nice contribution 😄
I think we can simplify the steps definition by using the headersByUsername tzatziki feature.

  * Setup authentication for user logged_user with clientId "my-service" with clientSecret "secret123" and token url "http://auth-server/oauth/token"

In your step if you call addHeader for "logged_user" with access token directly then you can directly call with authenticated user using existing http calls steps:

# Simple GET request
When logged_user call "http://backend/api/resource"

# POST with body
When logged_user post on "http://backend/api/users" with:
  """json
  {
    "name": "John Doe"
  }
  """

So finally, only one step to implement that call OAuth2ClientCredentialsStore to either register client and get access token or only get access token if client is already registered by another scenario. And then add the token as header for the user.

Last thought, maybe we should handle the refresh of the access token in case persisted between test and it expired during test campaign

[alexandrepa]

Maybe we can also add a test in case auth server failed to respond.

[gitguardian]

⚠️ GitGuardian has uncovered 7 secrets following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

Since your pull request originates from a forked repository, GitGuardian is not able to associate the secrets uncovered with secret incidents on your GitGuardian dashboard.
Skipping this check run and merging your pull request will create secret incidents on your GitGuardian dashboard.

🔎 Detected hardcoded secrets in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
-	-	Base64 Basic Authentication	c3f956b	tzatziki-http/src/test/resources/com/decathlon/tzatziki/steps/http.feature	View secret
-	-	Base64 Basic Authentication	c3f956b	tzatziki-http/src/test/resources/com/decathlon/tzatziki/steps/http.feature	View secret
-	-	Base64 Basic Authentication	c3f956b	tzatziki-http/src/test/resources/com/decathlon/tzatziki/steps/http.feature	View secret
-	-	Base64 Basic Authentication	c3f956b	tzatziki-http/src/test/resources/com/decathlon/tzatziki/steps/http.feature	View secret
-	-	Base64 Basic Authentication	53f7677	tzatziki-http/src/test/resources/com/decathlon/tzatziki/steps/http.feature	View secret
-	-	Base64 Basic Authentication	bb186ca	tzatziki-http/src/test/resources/com/decathlon/tzatziki/steps/http.feature	View secret
-	-	Base64 Basic Authentication	c3f956b	tzatziki-http/src/test/resources/com/decathlon/tzatziki/steps/http.feature	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secrets safely. Learn here the best practices.
3. Revoke and rotate these secrets.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}

[ozozgun]

First, thanks for this nice contribution 😄 I think we can simplify the steps definition by using the headersByUsername tzatziki feature.

  * Setup authentication for user logged_user with clientId "my-service" with clientSecret "secret123" and token url "http://auth-server/oauth/token"

In your step if you call addHeader for "logged_user" with access token directly then you can directly call with authenticated user using existing http calls steps:

# Simple GET request
When logged_user call "http://backend/api/resource"

# POST with body
When logged_user post on "http://backend/api/users" with:
  """json
  {
    "name": "John Doe"
  }
  """

So finally, only one step to implement that call OAuth2ClientCredentialsStore to either register client and get access token or only get access token if client is already registered by another scenario. And then add the token as header for the user.

Last thought, maybe we should handle the refresh of the access token in case persisted between test and it expired during test campaign

Thanks for the suggestion, indeed I did not see that was already possible. I have done the changes and removed the unnecessary new step definitions.
As agreed upon, we will implement the token refresh in another PR.

[jak78dkt]

Thanks for the contribution! That's awesome!
However, I’m going to request a change regarding the step naming. In the Tzatziki/Gherkin philosophy, we follow a declarative style for our steps. Starting a step with a verb (like "Setup") is an imperative pattern that breaks consistency with the rest of our steps naming.
To align with our standards, please update the step to a declarative format. For example:

Given that the user "user" is authenticated with clientId "my-service", clientSecret "secret123" and token url "http://auth-server/oauth/token"

Or, alternatively (for a shorter, maybe more readable step):

Given that the user "user" is authenticated with:
client_id: my-service
client_secret: secret123
token_url: "http://auth-server/oauth/token"

This consistency is essential for me. Once this is updated, I'll be happy to approve!

[jak78dkt]

See my comment