authservice should share both the ID token and the access token with the app

[cfryanr]

Currently the authservice fetches both the id token and the access token from the OIDC provider. It then saves the ID token into a browser cookie, and sets the ID token into the Authorization header for the app.

We believe that some apps would prefer to receive the access token, some apps may want to the ID token, and some apps may want both.

Our suggestion is to make this configurable. One possible way to make this configurable would be to expose two new configuration options:

1. The name of the http header which the authservice should use to transmit the access token to the app. This could default to Authorization, since the Authorization header is typically used for access tokens for APIs. The content of this header would be Bearer <token> where <token> is the JWT token value, since this is the standard format for oauth tokens passed via the Authorization header.

2. The name of the http header which the authservice should use to transmit the ID token to the app. This could default to X-AuthService-ID-Token. Perhaps just to be consistent, this should also be passed in the Bearer <token> format. That way, if the user overrides the default and configures this value to instead be Authentication then it would be correctly passed in the bearer token format.

If the user accidentally configures both of these options to be the same header name, then perhaps a reasonable behavior would be for the authservice to log a warning and then send only the ID token using that header name (or maybe log an error and abort).

[cfryanr]

I wonder if common application libraries (e.g. Spring) would know how to interpret an Authorization header that looks like this?

Authorization: Bearer <access_token> <id_token>

Perhaps something to try.

In addition to checking common libraries, we would also need to make sure that Istio's authn jwt token checking filter also supports this.

If they do, then when the user configures both header configuration options to be the same, then perhaps the authservice could use this format instead of erroring out.

[nickrmc83]

My feeling with this one is to put each token in separate cookies and headers so that we do not have to worry about breaking the size limits of those fields.

I'm also thinking that the access token is an opt-in whilst we always include the id_token. I'm assuming that we provide the capability to define the name of both the cookie returned to the browser as well as the header that we forward the access token.

Thoughts?