Re: OAuth re-authorization after losing tokens

[Daniel Roesler]

As requested, below is previous email that I sent regarding
reauthorization a while back.

Daniel Roesler
Co-founder & CTO, UtilityAPI
dan...@utilityapi.com



On Wed, Jul 22, 2015 at 3:23 PM, Daniel Roesler <dan...@utilityapi.com> wrote:
> Howdy,
>
> As requested, here's the OAuth scenario we are looking to solve:
>
> 1. TP redirect user to DC scope selection.
> 2. User approves TP and scope.
> 3. DC redirects user to TP with scope parameter.
> 4. TP redirects users to DC's OAuth /authorize endpoint with scope and
> client_id parameters.
> 5. DC redirects back to TP redirect_uri with OAuth code parameter.
> 6. TP makes a request to DC's OAuth /token endpoint with the code.
> 7. DC responds with an access_token and refresh_token.
> 8. TP's server crashes and doesn't save either token.
>
> How is the TP supposed to get new tokens? In normal OAuth, you simply
> redirect the user back to the OAuth /authorize endpoint, the user
> approves access again and gets redirected back with a new code.
>
> However, at least in the current PG&E implementation, the TP has to
> redirect the user to PG&E's scope selection screen, where the user
> will be told that they have already authorized the TP with no option
> to re-authorize. In order to get new tokens, the use manually has to
> cancel authorization, which causes them to get redirected to PG&E's
> main MyEnergy website. Then the user manually has to go back to PG&E's
> scope selection screen and authorize the TP again.
>
> This re-authorization process is not ideal because it requires us
> training the user to cancel-then-manually-go-back-and-reauthorize,
> which is a very confusing and complex process and doesn't redirect the
> user back to the TP after cancellation.
>
> Two possible solutions:
>
> 1. On the DC's scope selection interface, have a re-authorize button
> if the user has already authorized the TP.
>
> 2. Allow TP's to redirect the user to OAuth's /authorize endpoint with
> the same scope, and have the DC ask for re-authorization at that
> point.
>
> Option 1 is better for GBCMD, in my opinion, because it also allows
> for the scenario where the TP loses the scope parameter, too. Option 2
> is the more technically correct OAuth procedure. All other OAuth
> services I can think of do Option 2, but they also don't require a
> pre-defined scope parameter for the /authorize endpoint (so there's
> nothing to lose).
>
>
> Daniel Roesler
> Co-founder & CTO, UtilityAPI
> dan...@utilityapi.com