gothic fails when auth provider responds with URL fragments about goth HOT 11 CLOSED

Let me add that I may be able to generate a PR to handle all of this, but I would need some guidance from you on how you would like to see configuration for the 'response_type' parameter to be exposed though the API.

from goth.

Hi,I'm traveling and have dubious Internet, so I'm not sure I can be of much help. I would definitely welcome a PR for this. Thanks.

from goth.

@flimzy Just ran into this myself. I think for Facebook it should be response_type=code (or just left blank, since I think that's the default), since the server can't access the URL fragment — only the client can. That would explain the error (at least it was the reason behind my error, and worked for me 😄).

from goth.

I definitely would welcome a PR for this.

from goth.

Sweet, I'll work on this over the next few days 😄

from goth.

@bentranter do you have any update on this.

from goth.

Hey @rakesh-eltropy, I do. The Oauth exchange where the user receives a token as part of a URL fragment is (as far as I know) only supposed to be used for when the client (ie, a front end web app) is handling the token as part of the implicit grant flow -- not part of the three legged Oauth flow that Goth typically uses. For Goth's purposes, I think only the response_type=code should be used, not response_type=token.

As for the PR I mentioned, I had just intended to show some type of error to the user if they selected response_type=token over response_type=code. If anyone agrees with that idea, I'd be happy to open a PR adding that behaviour.

from goth.

If it's easy to support response_code=token, why not do it? Oauth can be used in many ways, and even Oauth in Go may be used for client-side auth (via GopherJS, for instance, or a desktop app).

If there is a technical reason it literally doesn't make sense to support response_type=token, sure, don't support it, and instead generate an error. If, on the other hand, it's easy to support, why not? It's part of the spec, and many people use libraries in ways un-anticipated by authors.

In either case, updating the documentation would be a good idea, IMHO. It ought to explain either why response_type=token is unsupported, or why it might be inappropriate for certain workflows.

from goth.

Hey @flimzy, I totally agree with you, and I'd love for Goth to support as many Oauth use cases as possible, but this one is tricky to support. When the request is made from the provider to the callback URL, the token is in the URL fragment, and that URL fragment isn't accessible on the server. You can still make this work using some JavaScript by getting the value of that token from the browser (since the URL fragment is accessible there), and then sending it to the server so that the session can be created.

The GopherJS use case though is really interesting, I hadn't considered that. I wonder if it'd be better to support the implicit grant flow and response_type=token as something specifically for the GopherJS users, since it'd allow this library to work for them too. What does everyone else think? The way I see it (and there might be more viable options than this) there are three things we could do:

1. Not support response_type=token, show an error message to the user, and add docs mentioning Goth doesn't support it.
2. Support response_type=token, but add docs mentioning that the client must obtain the token from the URL fragment manually from the browser, and send it to the server so the session can be created.
3. Look into supporting the implicit grant flow with GopherJS. I'd be willing to do this if there's enough interest, I've written JavaScript clients that support that flow in the past so I'm pretty familiar with it.

from goth.

While I did try to work on this for a bit (mind you it was nearly two years ago), the added effort to support the implicit grant flow in GopherJS is just not worth the added complexity to the library (in my opinion).

I think we should document that we don't support any flow which requires the application to read a URL fragment (which I think is still just the implicit grant flow), and if there are more users who want to use Goth for this, maybe it's something we could consider for a V2.

I'll leave this open for a few more days to let others share their thoughts, and if there are no objections, then I'll close this issue and add documentation to mention that the implicit grant flow is not supported by Goth.

from goth.

Closing this due to age, and also because I don't think it's worth attempting to support the implicit grant flow in a primarily server-side language. Perhaps in the future with WebAssembly, it'd be worthwhile, but not right now.

from goth.