Closes #5913: Add new sessionToken scope

[vladikoff]

Relanding #5914

@grigoryk r?

[codecov-io]

Codecov Report

Merging #6155 into master will decrease coverage by <.01%.
The diff coverage is 0%.

@@             Coverage Diff              @@
##             master    #6155      +/-   ##
============================================
- Coverage     18.93%   18.93%   -0.01%     
  Complexity      436      436              
============================================
  Files           288      288              
  Lines         11287    11288       +1     
  Branches       1536     1536              
============================================
  Hits           2137     2137              
- Misses         8988     8989       +1     
  Partials        162      162

Impacted Files	Coverage Δ	Complexity Δ
...org/mozilla/fenix/components/BackgroundServices.kt	46.42% <0%> (-0.42%)	4 <0> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 32985af...857a3b2. Read the comment docs.

[grigoryk]

LGTM, provided both pairing and regular flows work :-)

[grigoryk]

Still seems to crash in @vladikoff 's local testing.

[grigoryk]

@vladikoff any updates on this?

[vladikoff]

@vladikoff any updates on this?

We should probably wait for Firefox 71.

@rfk do you have any other ideas? I am wondering if we can do something to "handle" crashes that happen if the OAuth code cannot be exchanged.

[grigoryk]

I'm fine with waiting for 71 (a month from now).

[rfk]

I'm fine with waiting for 71 (a month from now).

Depends how we feel about the experience on ESR.

The reason this is a problem on 70 but not 71, is that 70 uses BrowserID assertions for authorizing OAuth codes, while 71 directly uses its sessionToken. Since BrowserID assertions don't tell you what sessionToken was used to generate them, we can't track the sessionToken info through the OAuth code grant and use it to generate a cloned session on the other side.

ow that danny has landed phase 2 of the auth/oauth server merger, it's possible that we could do something more clever on the server-side here. For example, I believe BrowserID assertions embed the originating deviceId, we might be able to use that to look up the sessionToken that should be associated with a particular OAuth code.

Alternately, when claiming the code, the server could detect the case where we can't generate a sessionToken and could remove it from the list of granted scopes, rather than failing the whole request. The client would need to be prepared to handle the case where it doesn't get granted all the scopes it requested, but OAuth clients should in theory be prepared for that at any time.

[vladikoff]

@grigoryk Rebased!