Skip to content
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

[iOS/iPhone] AppAuth prevents redirect uri deeplink from azure b2c #635

Closed
weissmanuel opened this issue May 6, 2021 · 3 comments
Closed

Comments

@weissmanuel
Copy link

weissmanuel commented May 6, 2021

I'am working with azure b2c and configured an redirect uri deep link. If I successfully signed in in the web view I don't get the response due of the following code snipped in OIDAuthorizationService.m. As soon as I comment out the if condition it works as expected.

Using this pod wrapped by the flutter plugin https://pub.dev/packages/flutter_appauth

- (BOOL)resumeExternalUserAgentFlowWithURL:(NSURL *)URL {
  // rejects URLs that don't match redirect (these may be completely unrelated to the authorization)
  if (![self shouldHandleURL:URL]) {
    return NO;
  }
@rotoudjimaye
Copy link

rotoudjimaye commented Nov 8, 2021

Your suggestion to comment that code helped me track down the issue.

The deep link copied from the Azure Portal does not include a "path" component. Say you copied msauth.com.package.name://auth. When you run it, the redirect URL returned from the sign in flow looks like msauth.com.package.name://auth/?code=XXXX&state=YYYY. The matchesRedirectionURL function attempts to compare (down to the path component) the actual redirect URL msauth.com.package.name://auth/ with the original one msauth.com.package.name://auth but they don't match.

The fix seems simple: append a forward slash to redirect URL copied from Azure before passing it to authorizeAndExchangeCode of the flutter plugin.

@guidedways
Copy link

Ideally shouldHandleURL: should be a method that the client calls before calling resumeExternalUserAgentFlowWithURL. This is how most other external URL handling services behave and this way the client gets an opportunity to accept a particular URL it knows is fine to be handled.

@petea
Copy link
Collaborator

petea commented Aug 18, 2022

Duplicate of #446

@petea petea marked this as a duplicate of #446 Aug 18, 2022
@petea petea closed this as completed Aug 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants