(Micha Sallé)
People might want to deal with tokens for multiple applications. (For instance: They want to do some kind of submission portal or similar). We implemented the forwarding part, so for example if you have an SSH access to submachine and you can SSH into it, and then if the agent is running there, he can talk to your local agent, so you keep your configuration information and refresh tokens safe because they are still local and only the access token is passed around.
The OIDC-agent application is a set of tools to manage OIDC tokens and make them easily manageable from the CLI.
OIDC-agent can communicate with trusted components (such as web browsers), which users may use to authenticate with the OIDC OP and obtain an access token, which may “pass” to desired applications.
There is a protocol that can save a certificate in a MyProxy server. It can obtain a short running proxy and this could be used to delegate your access to all the services. They consume a proxy and it lasts for a short amount of time. Whenever it is about to expire or it has already expired, we go back to the MyProxy server and require a new one. Problem: Nobody wants to use these certificates anymore.
Even if refresh tokens are stored, you should still force users to re-authenticate sometimes.
In proxy: There is an underlined certificate trust. All certificates are essentially issued by the trust component and they all follow the processes.
Clients cannot do a token exchange between themselves.
Clients should check if they are in the audience. If not, they should refuse the token.
