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

Feat: support universal links on iOS #247

Closed
raphael-yapla opened this issue Feb 8, 2024 · 3 comments
Closed

Feat: support universal links on iOS #247

raphael-yapla opened this issue Feb 8, 2024 · 3 comments

Comments

@raphael-yapla
Copy link

raphael-yapla commented Feb 8, 2024

Describe the Feature

As recommended by the OAuth 2.0 for Native Apps RFC claimed "https" scheme redirect URIs (or app links on Android/iOS) should be favoured for security reasons as they guarantee the domain ownership.

App-claimed "https" scheme redirect URIs have some advantages
compared to other native app redirect options in that the identity of
the destination app is guaranteed to the authorization server by the
operating system. For this reason, native apps SHOULD use them over
the other options where possible.

I got it working on Android using the following AndroidManifest.xml configuration:

<activity android:name="net.openid.appauth.RedirectUriReceiverActivity" android:exported="true">
    <intent-filter android:autoVerify="true">
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data android:scheme="https" android:host="your.domain.com" android:path="/login"/>
    </intent-filter>
</activity>

But on iOS I'm facing an issue when using an associated domain, the redirection is not caught because I think that the handler is not listening on the right event:

public override func load() {
    NotificationCenter.default.addObserver(self, selector: #selector(self.handleRedirect(notification:)), name: .capacitorOpenURL, object: nil)
    registerHandlers()
}

capacitorOpenURL is called for custom scheme links but for universal links a different application signature is called in the AppDelegate.swift which in turn calls the capacitorOpenUniversalLink notification instead.

Platform(s) Support Requested

  • iOS

Describe Preferred Solution

I've opened a PR with a simple fix, by registering the capacitorOpenUniversalLink notification observer the same way it's done with capacitorOpenURL the redirection is handled properly. So something like this:

public override func load() {
    NotificationCenter.default.addObserver(self, selector: #selector(self.handleRedirect(notification:)), name: .capacitorOpenURL, object: nil)
    NotificationCenter.default.addObserver(self, selector: #selector(self.handleRedirect(notification:)), name: .capacitorOpenUniversalLink, object: nil)
    registerHandlers()
}

Describe Alternatives

Not sure if there are any unfortunately 🤷

Thank you for all the work on this package!

@Seth-Know
Copy link

Seth-Know commented Jul 19, 2024

Using this, I continue to have the same problems discussed in here. I am not using the listener 'appUrlOpen' with this library, but the redirect simply loads the universal link instead of forwarding to the application just the same. I assume this happens because this library possibly uses the Capacitor Browser plugin which uses SFSafariViewController.

Only workaround that works for me is to require the user to login each time. No automatic logins or the redirect will simply load the universal link after initial prompt. I use Keycloak, so I use the following additionalParameters: {"prompt" : "login"}, in my OAuth2AuthenticateOptions config.

@raphael-yapla
Copy link
Author

raphael-yapla commented Jul 22, 2024

@Seth-Know I think I had a similar problem and what I ended up doing is adding a confirmation screen "Continue as x" for iPhone users when they still have a session instead of asking them to login again.

The problem in the original issue is that even after logging in the user would not get redirected to the app at all. I've been using my fork while waiting for this to be addressed in the meantime.

@moberwasserlechner
Copy link
Collaborator

Part of 6.1.0

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

Successfully merging a pull request may close this issue.

3 participants