FusionAuth
Allow dynamic redirect URI for OAuth
Allow dynamic redirect URI for OAuth
Problem
There are use cases in development and production where the redirect URI is either not full known, or can vary with request parameters.
The OAuth specification does not allow for wild cards, or a loose equality check on a registered redirect URI.
Solution
Some additional configuration options could help satisfy this request:
- Disable all
redirect_urivalidation - i.e. a "dev" mode or a "not secure" mode - Support regular expressions in defining the authorized redirect URIs in all of a portion of the URI
Alternatives/workarounds
- Register every possible redirect URI using the API. 🤮
- Encode necessary data into the
stateparameter.- https://tools.ietf.org/id/draft-bradley-oauth-jwt-encoded-state-08.html
Related
- https://github.com/FusionAuth/fusionauth-issues/issues/425
Additional context
Some sections have been copied from the The OAuth 2.0 Authorization Framework : RFC 6749 and the latest draft version of the OAuth 2.0 Security Best Current Practice (draft 13).
RFC 6749 Section 3.1.2.3 : Dynamic Configuration
If multiple redirection URIs have been registered, if only part of the redirection URI has been registered, or if no redirection URI has been registered, the client MUST include a redirection URI with the authorization request using the "redirect_uri" request parameter.
When a redirection URI is included in an authorization request, the authorization server MUST compare and match the value received against at least one of the registered redirection URIs (or URI components) as defined in [RFC3986] Section 6, if any redirection URIs were registered. If the client registration included the full redirection URI, the authorization server MUST compare the two URIs using simple string comparison as defined in [RFC3986] Section 6.2.1.
RFC 6749 Section 10.6 : Authorization Code Redirection URI Manipulation
In order to prevent such an attack, the authorization server MUST ensure that the redirection URI used to obtain the authorization code is identical to the redirection URI provided when exchanging the authorization code for an access token. The authorization server MUST require public clients and SHOULD require confidential clients to register their redirection URIs. If a redirection URI is provided in the request, the authorization server MUST validate it against the registered value.
RFC 6749 Section 10.15 : Open Redirectors
The authorization server, authorization endpoint, and client redirection endpoint can be improperly configured and operate as open redirectors. An open redirector is an endpoint using a parameter to automatically redirect a user-agent to the location specified by the parameter value without any validation.
Open redirectors can be used in phishing attacks, or by an attacker to get end-users to visit malicious sites by using the URI authority component of a familiar and trusted destination. In addition, if the authorization server allows the client to register only part of the redirection URI, an attacker can use an open redirector operated by the client to construct a redirection URI that will pass the authorization server validation but will send the authorization code or access token to an endpoint under the control of the attacker.
IETF OAuth Security Topics 4.5.2 : Discussion
But this approach conflicts with the idea to enforce exact redirect URI matching at the authorization endpoint. Moreover, it has been observed that providers very often ignore the "redirect_uri" check requirement at this stage, maybe because it doesn't seem to be security-critical from reading the specification.
Other providers just pattern match the "redirect_uri" parameter against the registered redirect URI pattern. This saves the authorization server from storing the link between the actual redirect URI and the respective authorization code for every transaction. But this kind of check obviously does not fulfill the intent of the spec, since the tampered redirect URI is not considered. So any attempt to inject a code obtained using the "client_id" of a legitimate client or by utilizing the legitimate client on another device won't be detected in the respective deployments.
How to vote
Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.
Based on some initial reading of the security recommendations from the specifications, we could also enforce a confidential client (require them to pass in the client_id and client_secret when calling the token endpoint) if they are using any "fuzzy" redirect_uris.
Similarly, we should determine the attack vectors for logout_uris and determine if this same issue needs to be managed there.
In the case of the WoltLab forum, we have to add a security token as parameter while logout:
https://DOMAIN.com/index.php?logout/&t=76e21c87e2c284cadbbb14bd2703088fd57de510
The security token will be changed after a page refresh so that it is impossible to add all security tokens to the fa application.
Do you have any ideas for a workaround?
Maybe I'm doing something wrong but I want to use the ionic-appauth package with FusionAuth but it is not possible to add the expected redirect URI (appauth://implicit/authcallback) to the authorized redirect urls. The spec talks about URI so it should be possible to add this entry, shouldn't it? Does anybody know a workaround? Maybe adding it to the db directly or something?
In the case of the WoltLab forum, we have to add a security token as parameter while logout:
https://DOMAIN.com/index.php?logout/&t=76e21c87e2c284cadbbb14bd2703088fd57de510The security token will be changed after a page refresh so that it is impossible to add all security tokens to the fa application.
Do you have any ideas for a workaround?
You may log out the user in WoltLab first and then redirect to FusionAuth's logout URI and after that back to the forum. This is what we do for this purpose.
@Jank1310 you are unable to add a redirect for appauth://implicit/authcallback?
Yes, i cannot add this uri as an entry in the authorized redirect urls list. It shows an validation error.
I wanted to note that OAuth 2.1 requires exact matching of redirect URIs: https://tools.ietf.org/html/draft-parecki-oauth-v2-1-03#section-3.1.2
Thinking of closing this issue out since this would be out of spec, and the OAuth 2.1 spec is doubling down on the requirement to use exact URI matching.
Questions:
- Is anyone aware of another IdP that supports this type of behavior, if so, can you provide a link or documentation of this feature?
- If we were to add this, do you need it for production or development?
Thanks!
@robotdan I believe Keycloak does this.
Relevant documentation excerpt:
Valid Redirect URIs
This is a required field. Enter in a URL pattern and click the + sign to add. Click the - sign next to URLs you want to remove. Remember that you still have to click the Save button! Wildcards (*) are only allowed at the end of a URI, i.e.
http://host.com/*
@robotdan Auth0 also allows this. From their docs:
Set of URLs to which Auth0 is allowed to redirect users after they authenticate. [...] You can use the star symbol as a wildcard placeholder for subdomains (*.google.com)
They specify it's only for subdomains, but I think this will cover all use cases as using wildcards for domain names would be too broad. I understand this is out of the spec, but maybe it could be implemented as a development feature? (Ie. only allowed for non-production instances).
For example, in our company, we are going to start using Vercel to deploy our app and we would like to have deployment previews enabled. As you probably know, each preview has its own unique URL; so we'll have to do some hacky workarounds with the CI pipeline to add those URLs to FusionAuth via the API and then remove them as we don't want the application to end up with hundreds of URLs.
Thanks for the feedback @alessandrojcm . Please make sure you upvote this too (I can't tell from the GH UI if you have).
Thanks for the feedback @alessandrojcm . Please make sure you upvote this too (I can't tell from the GH UI if you have).
No prob, yes I just upvoted :smiley:
If we were to ship an option to allow any redirect, or to allow wild cards in the configuration, would it be sufficient to allow this while in development mode? Or do you also think it is a necessary feature for production usage? (Note, it is considered a security risk to do this, particularly in production).
Please add your comments to these questions.
If we were to ship an option to allow any redirect, or to allow wild cards in the configuration, would it be sufficient to allow this while in development mode? Or do you also think it is a necessary feature for production usage? (Note, it is considered a security risk to do this, particularly in production).
Please add your comments to these questions.
For my particular use case, allowing it in development would be enough.
If we were to ship an option to allow any redirect, or to allow wild cards in the configuration, would it be sufficient to allow this while in development mode? Or do you also think it is a necessary feature for production usage? (Note, it is considered a security risk to do this, particularly in production).
Please add your comments to these questions.
My use case is that I am using an OAuth app to login the user with a basic scope (just user), and then giving some users the option later to upgrade that scope to also include repo.
The callback path for logging in is Auth0. But later, I want the callback path for the repo scope permission to be some non-authentication route in my own app.
This exact use case is given as an example in the Authorizing OAuth Apps docs but it seems to assume that in both instances the developer will want to redirect to an authentication callback.
For our use-case, we would require wildcard support also in production. For security reasons, I would only allow wildcards in the path of the URL (f.e. https://subdomain.domain.com/* or https://subdomain.domain.com/part/*) . Adding wildcard support to subdomains is probably less secure. The auth0 documentation also contains some relevant info about URL placeholders:
https://auth0.com/docs/get-started/applications/wildcards-for-subdomains#wildcard-url-placeholders
very helpful! ti should be possible on production with some validation with the origin or the referer or allowed domains for example configuration option.
This is available in the early access build of 1.43.0 if anyone is interested to give it a go before the general release.
https://fusionauth.io/docs/v1/tech/admin-guide/releases#early-access-program