Open chriswhitcombe opened 9 years ago
What do you mean by "implicit oauth2 flow" ?
Andrew,
The RFC lists 4 flows https://tools.ietf.org/html/rfc6749#section-1.3.2 and from what I can tell the library supports the Authorization Code (the default), Resource Owner Password Credentials (PasswordCredentialsToken function) and Client Credentials (the client credentials package).
I did some testing last night and its possible to create a config, get the auth URL, swap the grant type, hit the URL and get a access token back. I can then create a token and a valid client using this library.
There's a gist for this here https://gist.github.com/chriswhitcombe/ffc640fb7d07c58f8e5b which is pretty hacky, but demonstrates the idea.
I wasn't sure if there was another way to do this using the library, but I cant find one. The backend server i'm using is developed against https://github.com/RangelReale/osin and the gist works as expected.
The implicit grant flow doesn't work with golang because you have no (sane) way of catching the response as everything behind the hashtag isn't sent to the server as per RFC. So I guess the approach you proposed (hijacking the redirects) is the only possible imho. :)
This worked for us on Go 1.9.2.
c := &http.Client{}
resp, _ := c.PostForm(...)
values, _ := url.ParseQuery(resp.Request.URL.Fragment)
token := values.Get("access_token")
It would seem in the library there is no clear support for the implicit oauth2 flow. Is this deliberately missing as go is seen more as a server side language or is there a way to achieve it with the library.
I've been able to work around it somewhat by doing the auth call with a standard http client, then building a token, and creating a client from that. Though am just starting to test if that works. As implicit flow tokens don't have a refresh this would seem like a solution as you can use the client to add the correct headers, but wont gain the automatic refresh.
I just wanted to check if this is the suggested approach to implementing this flow?