You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Xcode 14 (2022) deprecated storyboards for watchOS making SwiftUI lifecycle apps the only 'official' way to make a watch app
VisionOS will be SwiftUI first
Many of the latest features require SwiftUI so developers will continue to adopt it (Widgets, Life Activities, etc.)
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.
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
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
The text was updated successfully, but these errors were encountered: