We currently only allow RPs to specify a single redirectURI. As part of the Lockbox->Lockwise name transition, the team would like to change redirectURIs while keeping the same client_id. One way to do this would be to allow a 2nd redirectURI to the list of allowed redirectURIs for a transition period while folks are updating their apps, and after the transition period is over, remove the original.
The DB stores redirectUri as a VARCHAR(256), and the check for the match in the /authorization route is done here.
The content server does a similar check but then builds it's OAuth redirectUri based on the redirectUri passed in via the query parameters.
If we allowed the stored redirectUri to be a comma separated list of URIs, we could achieve this functionality w/o too much fuss. VARCHAR(256) might be a bit short to allow for more than a couple URIs, though the clients table is small and enlarging this column should not be much trouble if we ever find we need to.
We should use exact matches, if the specified redirectUri matches any of those provided, then allow it. We would probably not want to go full pattern matching, there are a bunch of gotchas.
If multiple redirectUris are allowed and none is specified in the /authorization request, use the first registered URI as the default.
For good background info on securing a redirect flow, see the latest OAuth Best Common Practices draft.
Ref https://bugzilla.mozilla.org/show_bug.cgi?id=1547323
┆Issue is synchronized with this Jira Task
We currently only allow RPs to specify a single redirectURI. As part of the Lockbox->Lockwise name transition, the team would like to change redirectURIs while keeping the same client_id. One way to do this would be to allow a 2nd redirectURI to the list of allowed redirectURIs for a transition period while folks are updating their apps, and after the transition period is over, remove the original.
The DB stores redirectUri as a VARCHAR(256), and the check for the match in the /authorization route is done here.
The content server does a similar check but then builds it's OAuth redirectUri based on the redirectUri passed in via the query parameters.
If we allowed the stored redirectUri to be a comma separated list of URIs, we could achieve this functionality w/o too much fuss. VARCHAR(256) might be a bit short to allow for more than a couple URIs, though the clients table is small and enlarging this column should not be much trouble if we ever find we need to.
We should use exact matches, if the specified redirectUri matches any of those provided, then allow it. We would probably not want to go full pattern matching, there are a bunch of gotchas.
If multiple redirectUris are allowed and none is specified in the /authorization request, use the first registered URI as the default.
For good background info on securing a redirect flow, see the latest OAuth Best Common Practices draft.
Ref https://bugzilla.mozilla.org/show_bug.cgi?id=1547323
┆Issue is synchronized with this Jira Task