18F/myusa

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_doorkeeper call 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_in

I 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

Related to #690 & #693?