Document /oauth/authorize vs /users/sign_in
dhcole opened this issue · 5 comments
We've been using https://alpha.my.usa.gov/oauth/authorize as our authorization URL. As part of troubleshooting an issue, I noticed that this endpoint doesn't seem to be documented (https://alpha.my.usa.gov/developer).
Instead, the docs point to https://my.usa.gov/users/sign_in?client_id=ABCD. When I try that endpoint on the alpha server though (https://alpha.my.usa.gov/users/sign_in?response_type=code&redirect_uri=http%3A%2F%2Flocalhost%3A1337%2Fapi%2Fauth%2Fcallback%2Fmyusa&client_id=[token]), users are taken to the profile edit page on MyUSA (https://alpha.my.usa.gov/profile#) instead of sent back to the redirect URI with a code.
So there may be two issues here: 1) document the difference between these endpoints, and 2) is the sign-in flow broken on the /users/sign_in endpoint?
cc @harrisj, following up on our Slack conversation.
According to a comment in the routes.rb file
Legacy implementation used POST /oauth/authorize for both the user facing authorization screen and the API endpoint to request a token ... so, we have to support it. Set this route before the
use_doorkeepercall so that this route takes precedence over the other doorkeeper routes.
I will investigate further, but it seems to be something that should be working and not redirecting.
Actually, it looks like I am wrong. I've tested out a local flow that starts by going to /oauth/authorize?client_id=&redirect_uri=http%3A%2F%2Flocalhost%3A9292%2Fauth%2Fmyusa%2Fcallback&response_type=code&scope=profile.email+profile.first_name+profile.last_name&state=REDACTED and it seems to start the process and then redirects to /users/sign_in
I think the flow we're doing is the basic authorization flow
Yes that's what I see too. Thanks for looking into this.
The issue is that endpoint is not documented. The one that is
(/users/sign_in) breaks the flow by taking the user to their MyUSA profile
instead of back to the client application.
On Friday, July 10, 2015, Jacob Harris notifications@github.com wrote:
Actually, it looks like I am wrong. I've tested out a local flow that
starts by going to
/oauth/authorize?client_id=&redirect_uri=http%3A%2F%2Flocalhost%3A9292%2Fauth%2Fmyusa%2Fcallback&response_type=code&scope=profile.email+profile.first_name+profile.last_name&state=REDACTED
and it seems to start the process and then redirects to /users/sign_inI think the flow we're doing is the basic authorization flow
https://github.com/doorkeeper-gem/doorkeeper/wiki/authorization-flow—
Reply to this email directly or view it on GitHub
#703 (comment).
How much do we want to be walking people through the OAuth2 flow vs. just encouraging them to use third-party libraries like omniauth instead