OAuth re-authorization after losing tokens

[Daniel Roesler]

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