rfk
commented
5 years ago It needs tests for the new grant_type, but here's what I was thinking for #2962. Key points:
- Creates a new file
grant.jscontaining shared logic for validating grant requests (is this client allowed that scope? is the user sufficiently authenticated?) and generating the corresponding tokens. - Refactors the
/authorizationroute to make it a bit easier to follow, and to use the shared logic. - Adds a new
grant_type=fxa-assertionin the freshly-refactored/tokenendpoint, which takes an identity assertion and directly grants the requested tokens. - Also updates the
/key-dataendpoint to use the shared logic, for completeness.
@shane-tomlinson what do you think, is this heading in a good direction?
For full context, the plan would be that #2954 uses grant_type=fxa-assertion to do direct oauth token grants from a sessionToken.
vladikoff
Fixes #2962. Requires #2946 as it's based off that commit.
Clients could previously use an FxA assertion to grant themselves OAuth access tokens via the /authorization endpoint in a style modelled after OAuth's "implicit grant" flow. But it's not really the implicit grant flow, the way we use it in practice much more closely resembles the "resource owner password credentials" flow. In particular, existing clients use it to directly create tokens for their own use, rather than to authorize tokens for another client.
This commit makes that functionality available on the /token endpoint instead, using
grant_type=fxa-assertion. This is better aligned with the way that the rest of OAuth works, closely mirroring thegrant_type=passwordflow and keeping a clear distinction between obtaining tokens for ones own use (always use the /token endpoint) versus authorizing them for someone else (always use the /authorization endpoint).It will hopefully help us avoid future footguns if we want to allow assertion-bearing clients to create things for their own use (such as refresh tokens) that are forbidden in the "implicit grant" flow proper.