Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
cfryanr opened this issue Sep 25, 2019 · 2 comments · Fixed by #42
Closed

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

cfryanr opened this issue Sep 25, 2019 · 2 comments · Fixed by #42
Assignees
Labels
enhancement New feature or request
Projects

Comments

@cfryanr
Copy link

cfryanr commented Sep 25, 2019

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 cfryanr added the enhancement New feature or request label Sep 25, 2019
@cfryanr cfryanr added this to the Alpha Release milestone Sep 25, 2019
@cfryanr cfryanr added this to To do in authservice Oct 2, 2019
@cfryanr
Copy link
Author

cfryanr commented Oct 5, 2019

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 nickrmc83 self-assigned this Oct 14, 2019
@nickrmc83 nickrmc83 moved this from To do to In progress in authservice Oct 17, 2019
@nickrmc83
Copy link

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
authservice
  
Done
Development

Successfully merging a pull request may close this issue.

2 participants