Closed rfk closed 5 years ago
Tentatively targetting next train, but it depends on some of the existing oauth changes that @vladikoff and I are working this on the current train cycle.
its OAuth code for tokens bearing the "oldsync" scope.
For completeness, it seems like this also needs to happen for the implicit grant flow on /authorization endpoint.
For completeness, it seems like this also needs to happen for the implicit grant flow on /authorization endpoint.
IMHO, we should stop doing implicit grants on the /authorization
endpoint and start doing them on the /token
endpoint, since our client apps only use this flow for granting tokens to themselves (which is what the /token
endpoint is conceptually about) rather than to other clients (which is what the /authorization
endpoint is conceptually about).
Obviously there's b/w compat concerns there though, so let's see how it shakes it in practice...
IMHO, we should stop doing implicit grants on the /authorization endpoint
from mtg:
createDevice with OAuth name if we can (might not be a true placeholders)
I'm spinning this off from https://github.com/mozilla/fxa-auth-server/issues/2880 in order to break the work down into smaller chunks.
When a new client connects to sync, we need to send a push notification to existing clients telling them about the new peer. This currently does not happen for clients that get sync access by requesting the "oldsync" OAuth scope. From discussion in https://github.com/mozilla/fxa-auth-server/issues/2880 the simplest way to do the right thing here, is to create a placeholder device record at the point where the new client exchanges its OAuth code for tokens bearing the "oldsync" scope.
Requires https://github.com/mozilla/fxa-auth-server/issues/2954 or similar functionality, so that the code->token exchanges happens in a place where we can create the placeholder device record.