One of the problems we’re encountering with the use of review apps, is the OAuth2 authentication process. Each application gets a custom, unique URL (good), but the OAuth2 authentication flow requires an absolute URI to be registered for the client. This causes problems as we either need to (a) allow for registration of a client dynamically, at deploy time; or (b) configure our OAuth2 authentication server to allow for registration of wildcard-based redirect_uris (which is a violation of the OAUth2 specification).
What solutions do you use to handle this scenario? Is the registration of wildcard URIs not a major problem, given it’s a “Accept anything that matches this pattern” rule, and we still control that system?
1 Like
Did you figure out a good way of dealing with that?
We ended up creating an intermediate application, that just accepted a URL with a query parameter, and returned a 302 to the value specified. We called it a “springboard”. As the redirect_uri value is only validated on the host+path portion, not the query string, it allowed it through.
For example,
GET https://springboard.example.com?target=https://www.google.com/
302 Redirect
Location: https://www.google.com
This would also retain any query parameters (ie state or code) that got returned:
GET https://springboard.example.com?target=https://www.google.com/&state=FOO&code=XYZ
302 Redirect
Location: https://www.google.com?state=FOO&code=XYZ
The apps are then configured to override the redirect_uri value used in the OAuth request when specified.
We have a hard-coded list of URL patterns the springboard service will redirect to, so we can’t redirect to just anything.
Not pretty, but it works.