Preparing an IAM instance for test purposes: how to get a refresh token without requiring any manual operation during the test?

[aldbr]

Hello,

We are adding some code within DIRAC to get tokens from IAM.
We would like to create a very simple integration test interacting with a test instance of IAM to make sure our code is working properly.
We would like to design a fully automated test (no user interaction).

To prepare this test:

• I have downloaded and launched an indigoiam/iam-login-service container as defined in the documentation.
• I have registered a client.

From here, I see three straightforward ways of getting tokens:

• using the authorization_code flow, but it requires manual action from a user.
• using the client_credentials flow, but the access token will not be bound to a specific user + I don't get a refresh token.
• using the password flow, which could be okay for testing purposes, but is going to disappear in OAuth2.1 from what I understand.

Thus, would you have any recommendations on how to get a refresh token without requiring manual operations from a user?
(For instance, manually adding a refresh token within the DB?)

Thanks a lot

[federicaagostini]

Hello, if the DIRAC service relies on a scope based authorization model you can use client_credentials (the RT is not issued since a new access token can be requested in an automated way given the credentials of the client).

In case for instance the service requires to know the groups a user belongs to, you could use the refresh_token flow.
For example:

• obtain a RT from an authorization code flow including the offline_access scope (you can use iam-test-client, or oidc-agent for instance)
• register a client with the refresh_token grant enabled
• store the RT, client_id and client_secret in a secure place of your automated environment
• use the refresh token flow as done in this example to get your AT.

Anyway, for testing purposes you could also use the password flow, knowing that as you say it is deprecated in the OAuth 2.1 draft.

[aldbr]

As I said, we would like to avoid adding a user in the loop for the tests, so we cannot afford getting an RT using the authorization_code flow. But anyway, the password will probably be valid for testing purposes for many years (:crossed_fingers:), so we are heading in that direction.

Thanks