starred/OAuthSwift

Fork 0

mirror of https://github.com/OAuthSwift/OAuthSwift.git synced 2026-04-26 12:45:52 +03:00

[GH-ISSUE #621] ASWebAuthenticationSession support #403

New issue

Open

opened 2026-03-03 16:48:25 +03:00 by kerem · 5 comments

kerem commented

2026-03-03 16:48:25 +03:00

Owner

Originally created by @raxityo on GitHub (Aug 26, 2020).
Original GitHub issue: https://github.com/OAuthSwift/OAuthSwift/issues/621

Hi,

I see that we have ASWebAuthenticationURLHandler that nicely supports ASWebAuthenticationSession.
However, it has two limitations:

It's marked as @available(iOS 13.0, ...).
- It could work in iOS 12.0+ by preventing the use of presentationContextProvider and prefersEphemeralWebBrowserSession.
It requires users to declare URI schemes in Info.plist and update the app delegate to hand-off the callback to OAuthSwift.
- This can be prevented by directly handing off the callback in the completion handler, making the overall setup and usage of OAuthSwift much simpler.

To overcome these limitations, I have added a class here. But if you guys think it can be helpful to be added in this library, I can create a PR in this repository.

Thanks!

Originally created by @raxityo on GitHub (Aug 26, 2020). Original GitHub issue: https://github.com/OAuthSwift/OAuthSwift/issues/621 Hi, I see that we have [`ASWebAuthenticationURLHandler`](https://github.com/OAuthSwift/OAuthSwift/blob/master/Sources/Handler/ASWebAuthenticationURLHandler.swift) that nicely supports `ASWebAuthenticationSession`. However, it has two limitations: 1. It's marked as `@available(iOS 13.0, ...)`. - It could work in `iOS 12.0+` by preventing the use of `presentationContextProvider` and `prefersEphemeralWebBrowserSession`. 2. It requires users to declare URI schemes in `Info.plist` and update the app delegate to hand-off the callback to `OAuthSwift`. - This can be prevented by directly handing off the callback in the completion handler, making the overall setup and usage of OAuthSwift much simpler. To overcome these limitations, I have added a class [here](https://github.com/raxityo/OAuthSwiftAuthenticationServices/blob/1.0.0/Sources/OAuthSwiftAuthenticationServices/ASWebAuthenticationSessionURLHandler.swift). But if you guys think it can be helpful to be added in this library, I can create a PR in this repository. Thanks!

kerem added the

enhancement

label

2026-03-03 16:48:25 +03:00

kerem commented

2026-03-03 16:48:25 +03:00

Author

Owner

@jrtibbetts commented on GitHub (May 9, 2021):

So was this class ever added to OAuthSwift? I wish it were.

@jrtibbetts commented on GitHub (May 9, 2021): So was this class ever added to OAuthSwift? I wish it were.

kerem commented

2026-03-03 16:48:26 +03:00

Author

Owner

@phatblat commented on GitHub (May 13, 2021):

@jrtibbetts ASWebAuthenticationURLHandler is the library's wrapper for ASWebAuthenticationSession. It has been a part of the library for a couple of years now.

@phatblat commented on GitHub (May 13, 2021): @jrtibbetts [`ASWebAuthenticationURLHandler`](https://github.com/OAuthSwift/OAuthSwift/blob/master/Sources/Handler/ASWebAuthenticationURLHandler.swift) is the library's wrapper for `ASWebAuthenticationSession`. It has been a part of the library for a couple of years now.

kerem commented

2026-03-03 16:48:26 +03:00

Author

Owner

@phatblat commented on GitHub (May 13, 2021):

@raxityo If we downgrade the minimum version of iOS that this handler requires then we can't expose those newer properties you mention. I for one am looking forward to using the prefersEphemeralWebBrowserSession property to get rid of the alert that appears before the web page is loaded.

Looking at your code, you didn't actually prevent the use of these properties, but rather only used them when on iOS 13.0+. This is a nice touch, but this OS-version-dependent behavior should certainly be documented. Would you be interested in opening a PR with this change?

Regarding the direct callback handoff, I am unsure whether this is the right way to handle this. When an app is using a custom URL scheme, this provides better security as it avoids the potential security issue where a second app implements the same URL scheme and intercepts the redirect.

However, if an app uses Universal Links (https://example.com/oauth2redirect?code=...), this might introduce an attack vector by not going through the iOS URL-loading system.

@phatblat commented on GitHub (May 13, 2021): @raxityo If we downgrade the minimum version of iOS that this handler requires then we can't expose those newer properties you mention. I for one am looking forward to using the `prefersEphemeralWebBrowserSession` property to get rid of the alert that appears before the web page is loaded. Looking at your code, you didn't actually prevent the use of these properties, but rather only used them when on iOS 13.0+. This is a nice touch, but this OS-version-dependent behavior should certainly be documented. Would you be interested in opening a PR with this change? Regarding the direct callback handoff, I am unsure whether this is the right way to handle this. When an app is using a custom URL scheme, this provides better security as it avoids the potential security issue where a second app implements the same URL scheme and intercepts the redirect. However, if an app uses Universal Links (https://example.com/oauth2redirect?code=...), this might introduce an attack vector by not going through the iOS URL-loading system.

kerem commented

2026-03-03 16:48:26 +03:00

Author

Owner

@raxityo commented on GitHub (May 13, 2021):

@phatblat For sure, I am happy to create a PR to update the current implementation of ASWebAuthenticationURLHandler and update the docs. 👍

To address your concern about the direct hand-off:

When an app is using a custom URL scheme, this provides better security as it avoids the potential security issue where a second app implements the same URL scheme and intercepts the redirect.

When an app declares a custom URI scheme in Info.plist to handle the auth callback, it opens the doors for other apps to communicate from the outside. With ASWebAuthenticationURLHandler, there's no need to declare the custom URI scheme in the Info.plist or go through the AppDelegate to handle the custom URI scheme that eventually gets delivered to OAuthSwift. According to the docs of ASWebAuthenticationSession:

After the user authenticates, the authentication provider redirects the browser to a URL that uses the callback scheme. The browser detects the redirect, dismisses itself, and passes the complete URL to your app by calling the closure you specified during initialization.

As such, the custom URI scheme only gets shared to the ASWebAuthenticationSession. 🙂

@raxityo commented on GitHub (May 13, 2021): @phatblat For sure, I am happy to create a PR to update the current implementation of `ASWebAuthenticationURLHandler` and update the docs. 👍 To address your concern about the direct hand-off: > When an app is using a custom URL scheme, this provides better security as it avoids the potential security issue where a second app implements the same URL scheme and intercepts the redirect. When an app declares a custom URI scheme in `Info.plist` to handle the auth callback, it opens the doors for other apps to communicate from the outside. With `ASWebAuthenticationURLHandler`, there's no need to declare the custom URI scheme in the `Info.plist` or go through the AppDelegate to handle the custom URI scheme that eventually gets delivered to `OAuthSwift`. According to the [docs of `ASWebAuthenticationSession`](https://developer.apple.com/documentation/authenticationservices/authenticating_a_user_through_a_web_service#3395261): > After the user authenticates, the authentication provider redirects the browser to a URL that uses the callback scheme. The browser detects the redirect, dismisses itself, and passes the complete URL to your app by calling the closure you specified during initialization. As such, the custom URI scheme only gets shared to the `ASWebAuthenticationSession`. 🙂

kerem commented

2026-03-03 16:48:26 +03:00

Author

Owner

@myihsan commented on GitHub (Feb 2, 2022):

@phatblat
This comment seems that you misunderstand the purpose of ASWebAuthenticationSession or there is a design change.

I think ASWebAuthenticationSession is designed for using a custom URL without declaring it in the Info.plist as @raxityo mentioned above.
When using a universal link, we have to cancel the session by ourselves when UIApplicationDelegate.application(_:open:options:) is called since completionHandler will not be called even we set callbackURLScheme to "https". So, it's better to use SFSafariViewController.
However, I have no idea why callbackURLScheme can be nil.

So it looks good to me to use OAuthSwift.handle(url:) directly and needs to separate callbackURLScheme from the callbackURL used to create the error URL to avoid the issue you mentioned in the comment.
I would like to create a PR if my understanding is correct.

@myihsan commented on GitHub (Feb 2, 2022): @phatblat This [comment](https://github.com/OAuthSwift/OAuthSwift/issues/653#issuecomment-832198273) seems that you misunderstand the purpose of `ASWebAuthenticationSession` or there is a design change. I think `ASWebAuthenticationSession` is designed for using a custom URL without declaring it in the `Info.plist` as @raxityo mentioned above. When using a universal link, we have to cancel the session by ourselves when `UIApplicationDelegate.application(_:open:options:)` is called since `completionHandler` will not be called even we set `callbackURLScheme` to `"https"`. So, it's better to use `SFSafariViewController`. However, I have no idea why `callbackURLScheme` can be `nil`. So it looks good to me to use `OAuthSwift.handle(url:)` directly and needs to separate `callbackURLScheme` from the `callbackURL` used to create the error URL to avoid the issue you mentioned in the comment. I would like to create a PR if my understanding is correct.

kerem referenced this issue

2026-03-03 16:49:47 +03:00

[PR #403] [CLOSED] Retrieving only authentication code by specifying response_type as code #624