-
Notifications
You must be signed in to change notification settings - Fork 60
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
IdToken as part of PluginContext.User #579
IdToken as part of PluginContext.User #579
Comments
Related #506 |
It's been supported since Grafana v9.2 https://grafana.com/docs/grafana/v9.2/developers/plugins/add-authentication-for-data-source-plugins/#forward-oauth-identity-for-the-logged-in-user Starting from Grafana v9.4 there's some helpers available to operate on forwarded HTTP headers https://grafana.com/docs/grafana/next/developers/plugins/add-authentication-for-data-source-plugins/#forward-oauth-identity-for-the-logged-in-user |
Thanks, this unblocks scenarios when ID token needed.
Main reasons why I submitted this issue:
The Helpers make it cleaner but they still attached to request. |
Only in specific scenarios such as when OAuth provider is used for login
With the latest changes in the grafana-plugin-sdk-go you can pass
With the latest changes in the grafana-plugin-sdk-go you can do something like this: func WithUserFromReq(ctx context.Context, user *backend.User, req backend.ForwardHTTPHeaders) context.Context {
if req == nil {
return ctx
}
idToken := req.GetHTTPHeader(backend.OAuthIdentityIDTokenHeaderName)
token := strings.Fields(req.GetHTTPHeader(backend.OAuthIdentityTokenHeaderName))
var (
tokenType = token[0]
accessToken = token[1]
)
currentUser := CurrentUserContext{
User: user,
IdToken: idToken,
AccessToken: accessToken,
}
return WithCurrentUser(ctx, currentUser)
} Thanks for the valuable points. We'll consider this for the future, but not at the moment since we're not sure related things to user and context are about to change. You also have workaround in place. |
In addition, upgrade notes for v9.4.x: https://grafana.com/docs/grafana/next/developers/plugins/migration-guide/#from-version-93x-to-94x |
Additional proposal from the #506:
Since ID token is a key/value bag of claims describing the user, it could be parsed in advance for user convenience as a map of claims. In some casees the original token is useful ( The token would be set if Grafana authentication allows for ID token (e.g. OAuth), otherwise it would be set to |
@kostrse after consideration we've decided that this is convenient and added it via #1017 and will be available in the next release. |
What would you like to be added:
Extend the
backend.User
struct with ID token (here):So it could be accessed like this:
Why is this needed:
Currently ID tokens are being passed to plugins via
Headers
.The existing approach has the following problems:
CheckHealth
signature doesn't have headers. Currently there's no way to obtain ID token from the backend test func. This breaks scenarios like All requests should use user identity auth if user identity configured azure-data-explorer-datasource#509User
struct then it would be possible to passUser
across as a single entity (e.g. attach it toctx
and pass from business layer to transport layer etc.). This leads to a need to repackage the user identity into another custom entity to work with (example here).Headers
collection for this purpose is misleading.QueryDataRequest
andCallResourceRequest
even differ in definition ofHeaders
(map[string]string
vsmap[string][]string
). It is not a strongly-typed and it's error prone.Other things to consider
AccessToken
as well. But I don't have opinion on this,IdToken
alone should be enough for purposes of identification of the user, whileAccssToken
useful for token pass-through scenarios.User
struct intoctx context.Context
when callingQueryData
,CallResource
,CheckHealth
or any other backend plugin func.The text was updated successfully, but these errors were encountered: