mikenachbaur-okta
commented
1 year ago Hi @SwiftNativeDeveloper, thank you for reaching out! WebAuthenticationUI's "window anchor" argument comes from ASWebAuthenticationSession's ASWebAuthenticationPresentationContextProviding presentationAnchor property, and passes responsibility of supplying that along to you. (As a side note, WebAuthenticationUI uses this to provide a graceful fallback to SFAuthenticationSession and SFSafariViewController for older iOS versions. See the documentation on the version compatibility matrix for more details).
Fortunately the window anchor is an optional property, and if you supply nil, it should continue to function normally within both UIKit and SwiftUI applications.
You do bring up a good point that proper first-class support for SwiftUI would be desirable, particularly for WebAuthenticationSession. Is there anything that WebAuthenticationUI is unable to handle that supporting WebAuthenticationSession would? If you could provide more details on any issues you're facing, I'd be happy to help.
Supporting AuthorizationController is a bit more complex. If you could provide more details on what authentication flows or UX patterns you'd like to build using AuthorizationController, that could be very helpful.
In general the WebAuthenticationUI library is aimed at implementing web-redirect sign in, using the underlying Authorization Code Flow class. For more advanced use-cases, such as widgets, app extensions, or other similar scenarios, you can look at the other authentication flows supplied by the OktaOAuth2 library. One such example is Token Exchange Flow, which allows you to build what we call "Device SSO". This can permit your main application to sign in using WebAuthenticationUI, and using the keychain with Access Groups, can share a "device secret" which can be used to exchange tokens for each of your app extensions, without the need to sign in again. If you'd like to see an example of this in action, check out the "SingleSignOn" sample application, which signs a second application in using the device secret obtained by signing in using the web in the "WebSignIn" sample on the same device.
Describe the feature request?
There are any number of reasons why Apple is going to push SwiftUI as the best way to make apps on Apple platforms. To name a few:
As a result it is crucial to have sample code that illustrates how to use this Swift Package within SwiftUI Lifecycle and SwiftUI views. In the process of this activity, it will hopefully become evident that the API isn't friendly to SwiftUI. This gets a little messy around invoking the Authentication Services UI stuff since that is still only accepting anchors that are UIWindow. Not everyone is going to implement an App Delegate, nor a scene delegate if supporting more than once scene OR multitasking on iPad.
New or Affected Resource(s)
https://github.com/okta/okta-mobile-swift/tree/master/Samples
Provide a documentation link
Right now the API requires a window explicitly. This is in fact the type alias that Apple has in Authentication Services for the anchor for web login. https://github.com/okta/okta-mobile-swift/blob/master/Sources/WebAuthenticationUI/WebAuthentication.swift#L156
Additional overrides for the WebAuthenticationUI methods could instead take UIWindowScenes (or UIScene) could make this more friendly to use or give developers who have adopted scene delegate the last number of years hints. https://developer.apple.com/documentation/uikit/uiwindowscene
Apple introduced a number of updates to AuthenticationServices to support SwiftUI more elegantly in iOS 16.4 that should be looked at in the process for adopting within this package too :) https://developer.apple.com/documentation/authenticationservices/authorizationcontroller https://developer.apple.com/documentation/authenticationservices/webauthenticationsession
Additional Information?
No response