-
Notifications
You must be signed in to change notification settings - Fork 13
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Document the implication of using non-HTTP scheme redirect URI
ref #18
- Loading branch information
1 parent
0d46601
commit dc3852f
Showing
2 changed files
with
26 additions
and
0 deletions.
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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,23 @@ | ||
--- | ||
description: Implication of using non-HTTP scheme in redirect URI. | ||
--- | ||
|
||
# Non-HTTP scheme redirect URI | ||
|
||
If your application is a mobile application, you can choose to use custom URI scheme in the redirect URI. | ||
Custom URI scheme redirect URI does not require verification. | ||
Therefore, it is possible that there is a malicious application installed on the user's device, | ||
which claims itself capable of handling your redirect URI. | ||
|
||
The whole attack is as follows: | ||
|
||
1. The attacker generates a [code verifier](https://tools.ietf.org/html/rfc7636#section-4.1) and a [code challenge](https://tools.ietf.org/html/rfc7636#section-4.2). | ||
1. The attacker somehow makes the victim to install a malicious application on their device. The malicious application registers the same redirect URI that your application is using. | ||
1. The victim somehow is mislead by the attacker to visit the authorization endpoint with the code challenge generated in Step 1. | ||
1. The victim completes the authorization code flow and the malicious application receives the authorization code. | ||
1. The malicious application uses the code verifier in Step 1 and the just received authorization code to exchange for an refresh token and an access token. | ||
|
||
It is impossible to prevent malicious applications being installed on the user's device. | ||
However, we can mitigate this attack by not using custom URI scheme. | ||
|
||
To do so, you can use [Apple Universal Links](https://developer.apple.com/documentation/xcode/allowing_apps_and_websites_to_link_to_your_content) and [Android App Links](https://developer.android.com/training/app-links). |