Customizing the authorization endpoint in GoogleAuthenticationHandler

Aug 7, 2013 at 11:39 AM
For all the inversion of control and "plug-ability" afforded in Katana - the one thing that is hard coded in the GoogleAuthenticationHandler is the most important string that is passed to Google on line 317 for OAuth. What if you want more than email,name,first,last? What if you want to use another extension such as getting the OAuth token? Of all things, this should string should be extensible. I'm not sure where the "AuthenticationExtras" come into play, but you should be able to customize the construction of this string.
Aug 16, 2013 at 10:02 AM
Hey,

That's an interesting point: there's clearly a need for more extensibility. Maybe we should refactor it using an existing library such as DotNetOpenAuth (which needs new contributors since Andrew Arnott's resignation by the way!), as it handles attribute exchange in a very elegant and easy-to-abstract manner? ;)

That said, the set of attributes supported by Google is rather limited : "country", "email", "firstname", "language", "lastname" seem to be the only ones supported using OpenID2 (please see https://developers.google.com/accounts/docs/OpenID).

If you need more, I suppose you'll need to build your own handler pointing to their new "OpenID connect" endpoint - different from OpenID2 - (see https://developers.google.com/accounts/cookbook/technologies/OpenID-Connect) or using OAuth to get an access token and then querying their "People API" (see https://developers.google.com/accounts/docs/OAuth2Login#obtaininguserprofileinformation)

Good luck!
Sep 19, 2013 at 8:22 PM
I totally agree. Some more extensibility for the GoogleAuthenticationHandler is needed. I for instance would like to retrieve the language attribute, which could easily be added to the existing code:
string authorizationEndpoint =
    "https://www.google.com/accounts/o8/ud" +
        "?openid.ns=" + Uri.EscapeDataString("http://specs.openid.net/auth/2.0") +
        "&openid.ns.ax=" + Uri.EscapeDataString("http://openid.net/srv/ax/1.0") +
        "&openid.mode=" + Uri.EscapeDataString("checkid_setup") +
        "&openid.claimed_id=" + Uri.EscapeDataString("http://specs.openid.net/auth/2.0/identifier_select") +
        "&openid.identity=" + Uri.EscapeDataString("http://specs.openid.net/auth/2.0/identifier_select") +
        "&openid.return_to=" + Uri.EscapeDataString(returnTo) +
        "&openid.realm=" + Uri.EscapeDataString(requestPrefix) +
        "&openid.ax.mode=" + Uri.EscapeDataString("fetch_request") +
        "&openid.ax.type.email=" + Uri.EscapeDataString("http://axschema.org/contact/email") +
        "&openid.ax.type.name=" + Uri.EscapeDataString("http://axschema.org/namePerson") +
        "&openid.ax.type.first=" + Uri.EscapeDataString("http://axschema.org/namePerson/first") +
        "&openid.ax.type.last=" + Uri.EscapeDataString("http://axschema.org/namePerson/last") +
        "&openid.ax.type.language=" + Uri.EscapeDataString("http://axschema.org/pref/language") + // like this
        "&openid.ax.required=" + Uri.EscapeDataString("email,name,first,last,language"); // making it required here
Obviously we should be able to manipulate the list of parameters from the outside, like the Facebook and Microsoft authentication providers do through their Scope parameter lists.