ARC support for OIDC

Support level

Only tokens conforming to the WLCG profile have been tested. The current validation is not strict: the token is parsed and the signature is checked if present, but no additional requirements are imposed. Tokens are only accepted for client authentication during job submission through the EMI-ES and REST interfaces.

Obtaining and using tokens

The suggested way for obtaining a token is through the oidc-agent utility - Install it following the instructions for your Linux distribution.

Point your browser to and create an account.

Start the oidc-agent. It will print few lines of shell commands. Copy them to the command line and execute. This will set up environment variables for other oidc-* commands.

Start oidc-gen. It will guide you through the steps to register the OIDC client and create a profile for the oidc-agent. When asked to select the issuer, select When asked about the scope, write openid profile wlcg. You only need to run the oidc-gen once. Next time when you use the oidc-agent, you can load an already created profile with the ‘oidc-add NAME_YOU_CHOOSE’ command.

When the oidc-gen command tells you “To continue and approve the registered client visit the following URL in a Browser of your choice:” point your browser (which must be running on the same machine as the oidc tools do) to the adress given.

Obtain the token and store it in the BEARER_TOKEN variable:

export BEARER_TOKEN=`oidc-token NAME_YOU_CHOOSE`

If the oidc tools were installed on a different machine than your ARC client, then first obtain the token on the oidc tool machine:


Then copy the token string and on your ARC client machine do:

export BEARER_TOKEN=<token-string>

Now submit the job to an ARC CE with arcsub through the REST interface. For that, use the option ‘-T arcrest’. The token stored in the BEARER_TOKEN variable will be used instead of the X.509 certificate for authenticating the user to the ARC CE server. Note that arcsub still requires an X.509 proxy which will be delegated to the CE. Data staging currently will also still use the X.509 proxy credentials.

Note: You can use any other method for obtaining a WLCG compliant OIDC token. Just store it in the BEARER_TOKEN variable before calling arcsub.

Configuring authorization on server

Token processing is enabled by the presence of the [authtokens] configuration block.

The user can be authorized on the server by adding a dedicated command to the authgroup block:

authtokens=subject issuer audience scope group

The specified parameters must match those in the provided token. Parameters can be ‘*’ to match any value, for example

authtokens=e83eec5a-e2e3-43c6-bb67-df8f5ec3e8d0 * * *

matches a user with subject e83eec5a-e2e3-43c6-bb67-df8f5ec3e8d0 in token issued by .


Until handling of authtokens is integrated with arcproxy you will have to find the subject of the token using a tool like e.g. . Alternatively you can install flaat (

A full example configuration could look like


[authgroup: wlcg_iam]
authtokens = * * compute.create /wlcg/pilots
authtokens = * * /wlcg/pilots
authtokens = * * compute.modify /wlcg/pilots
authtokens = * * compute.cancel /wlcg/pilots

map_to_user = wlcg_iam wlcg:wlcg


User mapping to a local account is implemented using a simulated X.509 user subject. The subject provided by an OIDC token is unique only in scope of the identity provider. To generate a globally unique user-identifier, the issuer and the subject are cocatenated as “issuer/subject” to provide an identifier suitable for user mapping. For example, a user with subject e83eec5a-e2e3-43c6-bb67-df8f5ec3e8d0 in the token issued by is represented by a simulated identifier