-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow public clients (e.g. SPAs using implicit flow or PKCE) to have redirect URLs other than localhost #1822
Merged
sagikazarmark
merged 4 commits into
dexidp:master
from
faro-oss:feature/redirect-uris-for-public-clients
Nov 5, 2020
Merged
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
b894d9c
Allow public clients (e.g. using implicit flow or PKCE) to have redir…
heidemn-faro 1ea481b
Fix gofmt in oauth2_test.go
heidemn-faro c15e288
Add oob, device and localhost redirect URI tests
heidemn-faro 162073b
No longer allow desktop/mobile redirect URIs implicitly if RedirectUR…
heidemn-faro File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Our use case is to use PKCE for a web app that doesn't run on "localhost".
Therefore, we would like that
RedirectURIs
are also considered for public clients.PKCE was definitely also intended for web apps, and you can already configure such web apps e.g. in Okta or Auth0.
The following code to allow any localhost URI,
redirectURIOOB
ordeviceCallbackURI
for public clients is still active.An alternative could be to no longer allow these special URLs implicitly when
RedirectURIs
is non-empty.I don't have a strong opinion if this would be better. The maintainers should decide.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the implementation is good as it is. The alternative of not supporting the special URLs, when
redirectURIs
is defined, would break currently working configurations.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would personally prefer the logic to only allow whitelisted redirect uris, if the list is non-empty.
This would tighten the security and would not break existing configurations that do not use RedirectURIs for public clients.
And I bet the most configurations that do currently use it for public clients operate under the false assumption that the list is actually respected (I know we did in our deployment for some time).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I fear that there are configurations that may be working by accident, because currently it is possible to have the RedirectURIs wrongly configured, and it still works.
Let's see what the maintainers decide.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can fix that by properly documenting this change or mentioning it in the change log.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tkleczek AFAICT this is not the case now, but the rest of the conditions provide backwards compatibility and limit redirect uris to
redirectURIOOB
,deviceCallbackURI
orlocalhost
for public clients which seems fine. WDYT?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My concern is that for SPAs allowing localhost redirects seems like an unnecessary risk.
But if we care about potential backwards compatibility issues more, then I am fine with the change as it is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's actually true. Consider that e.g. a malicious desktop app could obtain a token intended for https://webapp.com , since the desktop app can run a server listening on http://localhost .
If the user is already logged in at the IDP in the browser, then this could probably be done without user interaction.
The desktop app could then call the API of https://webapp.com with the token.
So I would prefer not to allow these special URLs implicitly if
RedirectURIs
is non-empty.In the future, three additional boolean options could be added to explicitly (dis)allow each of
redirectURIOOB
,deviceCallbackURI
orlocalhost
-ish URLs. But this would definitely break backwards compatibility, and might be over-engineering.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sagikazarmark I added more tests for these special URIs in c15e288 .
Then I made the change suggested by @tkleczek in 162073b :
if !client.Public || len(client.RedirectURIs) > 0 { return false }
As you can see in the tests, it's still possible to explicitly add
redirectURIOOB
anddeviceCallbackURI
to theRedirectURIs
if needed. So most mobile/desktop/localhost apps should just continue to work, and all others just need to update their configuration.The only edge case that now doesn't work any more is a combination of 1) named
RedirectURIs
with 2)localhost
URIs with random port. (For desktop apps, random ports must be used, since any hard-coded port might be occupied by another application.)But this case is weird anyway (using the same client for web app + desktop app?). It can be solved by using two clients instead.
Please take another look.