Save token to context and session

[chrishalbert]

As part of the Auth()'s returned gin.HandlerFunc, the user is saved to the context and session. This is great for identification, however I'm running into an issue. During the google package's Setup(), my application is able to specify scopes to make subsequent requests on behalf of the user. The problem is that our token, which was issued with those scopes, is no longer available. To get a token this would require an additional or custom middleware be implemented. Since we are providing a means to specify scopes, I think its presumable that the application should be able to make requests on the user's behalf following authentication. With that, I was interested in modifying the Auth() function to save the token to the session and the context.

If I'm misunderstanding the flow or overlooking a way to not have to reinitiate the oauth2 flow, please let me know. I'm going to work up an MR in the mean time. Thanks!

[szuecs]

@chrishalbert this is a re-occuring discussion (not here, but internal). The reason why not storing a token is to not impersonate the user. UI component validates it's the right user and knows about the user to show and request only data for the given user. The frontend will need to call a backend component owning the database to get some data. I would always recommend for security reasons that the frontend will use a svc-to-svc token to authenticate to the backend instead of passing the user token. A user token can have much more access rights than only to the given backend, so if a backend leaks a token for example via logs it can easily loose control over the token and then you have a much bigger security scope than checking only the access to the backend.