Relax redirect URL matching for the forward slash path case

[AlexPlekhov]

Based on issue #446 sometimes a trailing slash added to path for redirect url.
Here a fix to make comparison regardless that trailing slash.

This issue affects react-native-app-auth lib:
FormidableLabs/react-native-app-auth#123
FormidableLabs/react-native-app-auth#336

and a few others.

[petea]

Thanks for the contribution @AlexPlekhov, could you sign the contributor agreements so we can get this merged?

[AlexPlekhov]

Hi @petea, I've already done it immediately after creating PR. I hope you got email notifications. If didn't I'm ready to send those PDFs via email.

[AlexPlekhov]

Thanks for the contribution @AlexPlekhov, could you sign the contributor agreements so we can get this merged?

Hi @petea, could you confirm that everything OK? I followed the steps in the contributor agreements. Please, write me back if I missed anything and still have to do something.

[ntherning]

Would be great to have this PR merged as it fixes an issue with Azure AD we have been experiencing. The Azure Portal gives us a redirect URI which looks like msauth.com.example.app://auth to use with our iOS app. But when the redirect back to our app happens they have appended a slash which breaks AppAuth's redirect URI validation. With the changes in this PR applied AppAuth happily accepts the redirect URI and proceeds.

[AlexPlekhov]

Hi all, @petea,

I've resigned all docs as required by Mike Leszcz, was added to a WG, got a subscription email.
But it's still in review. Have I missed anything again?

[developerfromjokela]

I think this should be merged, as this is mission critical for functioning apps that rely on third party services and thus cannot influence how the backend behaves.

[petea]

@developerfromjokela note that there are workarounds for this situation discussed in #446.

[AlexPlekhov]

@developerfromjokela note that there are workarounds for this situation discussed in #446.

Yep, we already did the same. But wants to help the community to not face with it again.

[davidkaya]

Hi @petea, will this get merged? We encountered this issue just today. We have support for multiple IdPs that support OIDC and customer wanted to use ADFS but it is not working cause ADFS appends / to the redirect uri 🤷🏽‍♂️

[petea]

@davidkaya note that there is a straightforward workaround for this issue that is detailed in #446.

[DelcoigneYves]

Can we get this PR moving again? I think the only remaining question is a missing comment? Would help in our case (using the Flutter AppAuth library where this is an issue as well (and mentioned workaround does not apply in our case)

[AlexPlekhov]

@DelcoigneYves
I did everything I could. Comments, formats - everything has been in place already.

[DelcoigneYves]

Then poking @petea for a merge 💯

[AlexPlekhov]

@DelcoigneYves @petea @davidkaya
Hi folks!
I give up. I see only resistance against this PR and ignorance.
May be you will be more successful to resolve this issue on your way.
I will close it soon.

[DelcoigneYves]

@petea LGTM! Can we please now merge it? 🙂 https://github.com/openid/AppAuth-iOS/blob/master/CONTRIBUTING.md#pull-request-reviews

[pawellaskowski]

Hi @petea, is this going to get merged?

[icanci01]

I’m encountering a similar issue in a React Native application that uses AppAuth on iOS. Interestingly, this works fine on Android, but iOS fails due to strict redirect URL matching.

The problem is that I have no control over the Identity Provider (IdP). The IdP rejects the client if I register the redirect URL with a trailing /, so I must use the version without the trailing slash. However, the IdP does append a trailing / when returning the authorization response, causing AppAuth’s strict path comparison to reject the redirect.

Requesting the IdP to change its behavior isn’t feasible, as adding a trailing slash for my client would risk breaking existing integrations.

Could we consider making the redirect URI/path matching more relaxed, or at least providing a configuration option where developers can specify alternative acceptable redirect URLs (e.g., allow both myapp://callback and myapp://callback/)?

The suggested workarounds from previous discussions didn’t solve this issue for me. I resorted to creating a custom patch that’s applied automatically during pod install, but this approach is fragile — any upstream file structure change in AppAuth forces me to maintain and update the patch manually.

I even tried intercepting/replacing the matching method at runtime, but had no success despite multiple attempts.

Could we please get an update on this Pull Request, or some guidance on a cleaner long-term solution? A small change upstream would greatly improve AppAuth’s flexibility for these kinds of real-world IdP inconsistencies.

[developerfromjokela]

I’m encountering a similar issue in a React Native application that uses AppAuth on iOS. Interestingly, this works fine on Android, but iOS fails due to strict redirect URL matching.

The problem is that I have no control over the Identity Provider (IdP). The IdP rejects the client if I register the redirect URL with a trailing /, so I must use the version without the trailing slash. However, the IdP does append a trailing / when returning the authorization response, causing AppAuth’s strict path comparison to reject the redirect.

Requesting the IdP to change its behavior isn’t feasible, as adding a trailing slash for my client would risk breaking existing integrations.

Could we consider making the redirect URI/path matching more relaxed, or at least providing a configuration option where developers can specify alternative acceptable redirect URLs (e.g., allow both myapp://callback and myapp://callback/)?

The suggested workarounds from previous discussions didn’t solve this issue for me. I resorted to creating a custom patch that’s applied automatically during pod install, but this approach is fragile — any upstream file structure change in AppAuth forces me to maintain and update the patch manually.

I even tried intercepting/replacing the matching method at runtime, but had no success despite multiple attempts.

Could we please get an update on this Pull Request, or some guidance on a cleaner long-term solution? A small change upstream would greatly improve AppAuth’s flexibility for these kinds of real-world IdP inconsistencies.

Seems rather hopeless trying to get this merged, 2 years oh boy. maybe starting a fork with the patch is worth it?

[icanci01]

@developerfromjokela Yeah, starting a fork with the patch is definitely an option, but it comes with a few drawbacks. Maintaining a fork means I have to keep it in sync with upstream, manually merge updates, and ensure compatibility with future iOS/React Native changes. It works as a quick fix sure.. but I don't want to have another burden... I think for now patching the file during pod install might be the easiest fix for me.. :) will just have to make sure with future updates to update my patch file...

I think the issue with this pull request is that the reviewer @petea seems to not be active anymore..

Can we have someone else that is actively maintaining this to have a look?