The Authorization Code that follows from an authorized request is not exchanged for tokens as no subsequent request to the token endpoint is made. Setting breakpoints within the calling function will not yield an error, nor will an error be present in the Okta System Log.
Root cause was determined to be a redirectURI specified with camel case. More specifically, Safari and Okta will allow upper/mixed-case URIs but Safari will cast these values to lower-case after the redirect from Okta.
Example of erroneous redirectUri within the Okta.plist recommended configuration file:
com.example.iOSSample:/login
Example of proper and erroneous redirectUri allowed within a native application's General settings tab (Okta UI):
In this flow, the default (likely Safari) browser will open with the following code execution:
oktaOidc.signInWithBrowser(from: self) { stateManager, error in
//Handle error
if let error = error {
...
return
}
//Handle stateManager
...
}
If a redirectUri is specified with upper/mixed-case, the authorization request will proceed nominally but no error or stateManager objects will be accessible. The SDK library itself fails to finalize the task and no /oauth2/<id>/v1/token request will be made. However, the browser will route back to the application as expected. Due to Safari treating all URI values as lower-case, the event handler does not properly fire after Okta returns the authorization code.
Notes: Okta does respect upper/mixed-case URI values. If this mixed case example were not added as such to the Application's General -> Login: Sign-in redirect URIs, an error would be visible in the browser stating that the redirect URI used is not allowed.
Ensure that the redirectUri is specified in lower-case within the iOS project configuration file (Okta.plist, Info.plist, etc).
Ensure that the above redirectUri is also specified as lower-case within the Okta Application's General > Login:
Sign-in redirect URIs list.
