Request more than one info url

[joscha-alisch]

After authentication with my provider (GitHub) I would like to fill the token.User with additional info like the organizations/teams they are in to allow RBAC later on. Unfortunately, it seems like the access token is only used to retrieve the infoURL and avatar and is discarded afterwards.

Is there some functionality in this to use the access token to do another request in MapUserFn or ClaimsUpd? If not, do you think it would be possible to add another hook for this? Something like

GetUserInfoFn(client *http.Client) provider.UserData

that would by default do the current implementation

uinfo, err := client.Get(p.infoURL) 

but could be overridden with a custom implementation?

[umputun]

Generally, I think this is a nice idea to allow custom GetUserInfoFn to be provided optionally. However, oath2 providers also force the scope, like here and that custom user mapper will be limited to the predefined (usually the minimal) scope only. Maybe it makes sense to allow passing the scope as well?

[umputun]

another thing - I don't think the custom GetUserInfoFn should do the basic part at all. I.e. the basic mapping for ID, name, and picture is kind of a must-have anyway, and making the user's function to repeat the current implementation of the mapUser won't be too friendly.

Probably we may want some ExtraUserFn to be invoked as a part of mapUser and it won't touch the current fields but will be able to fill free-form User.Attributes

[joscha-alisch]

Thanks @umputun. I think both of your remarks make a lot of sense.

Where do you think would be a good place to add this on the API surface?

1. Just make it available for AddCustomProvider (this one has configurable scopes already)
2. Adapting Params in NewGithub(p Params) to allow using the predefined one and instantiating it via AddCustomHandler
3. Add an "overload" for AddProvider(name, cid, csecret string) like AddProviderWithOptions(name, cid, secret string, scopes []string, extraUserFn)

No 3 would be the most useful from my point of view. But you probably have a better overview and can think of issues with those approaches/other ideas?

[joscha-alisch]

I went ahead and created a draft PR for this, as the implementation seemed simple enough. Let me know how you feel about it :)