Add support for bearer token discovery

[bbockelm]

Several of our command line tools are beginning to utilize the WLCG bearer token discovery protocol:

https://github.com/WLCG-AuthZ-WG/bearer-token-discovery/

The protocol outlines where a command line tool should discover a token in its POSIX environment.

Is it possible to have oidc-token to support this protocol? Two ideas come to mind:

1. Add a new flag to oidc-token, -w, to write it out to the well-known location for the user.
2. Introduce a new bash function, set by the output of the oidc-agent startup, that does the equivalent of this:

export BEARER_TOKEN=`oidc-token $FOO`

Without this, we have to tell users to do things like this:

oidc-token WLCG-PILOT > $XDG_RUNTIME_DIR/bt_u`id -u`

Which is mysterious magic to most folks.

[zachmann]

I'm hesitant to add support for this to oidc-token. I also want to hear @marcvs opinion on this. Unfortunately, he's currently on vacation.

One major idea when we started implementing oidc-agent was that applications should be able to easily obtain a valid AT.
We wanted to go away from tokens in environment variables and files. The problem these approaches have is that the token eventually expires and that the user has to ensure that the env var contains a valid token.
IMHO the better approach is that applications that need an AT directly request it from oidc-agent through the IPC API.
To ease this we provide libraries for C, Python, and go. Another "API" that is used by some applications is oidc-token. There are application that allow to set a command which output they use as the AT.

By letting the application request an AT instead of relying on an already existing AT, the application can easily obtain an AT that is guaranteed to be valid. (Advanced applications can also profit from requesting multiple ATs with different scopes / audiences.)

I guess we agree that this would be the preferred solution, but requires support by the applications. That's why we also have some support for environment variables in oidc-token.

For example the -o option takes the name of an environment variable and oidc-token prints the commands needed to set the env var to the token value.
Unfortunately, we cannot automatically set the env vars, so one has to do one of the following:

• Use eval: eval `oidc-token -oBEARER_TOKEN https://wlcg.cloud.cnaf.infn.it/`
• Redirect output to a file, (make it executable,) and execute it.

I know that both of these suffer from the same shortcoming as your last suggested command: For the average-guy this is much more complicated then just calling oidc-token <shortname/issuer>.

I see that a -w / --write / --out option (-o is already taken) to specify an outputfile can help with some aspects.

I still think that oidc-token is not the right place to add full support for this specific problem.
The linked document mentions "higher-level tools" that might set the $BEARER_TOKEN_FILE before calling "lower-level tools".
Such a higher-level tool could be a simple script, similar to the one you suggested: It calls oidc-token to obtain the AT and prepares the environment before calling the actual application.