SessionTokenFlow 'start' function error

[ntorrescodigodelsur]

Describe the bug?

We are using the SessionTokenFlow to sign-in users into our app, which includes an SMS verification feature. When invoking the start function of the SessionTokenFlow, we encounter an "Invalid key data" error, even if we force a call to Credential.default?.remove() beforehand. This issue is peculiar because it is not specific to any user; rather, it is related to certain devices. We observe that signing in works on some devices but not on others. The only solution we have discovered so far is to uninstall the app and reinstall it.

The sessionToken parameter that we are using is the one that we receive in the OktaAuthStatusSuccess object and it’s correctly formed.

func authenticate(sessionToken: String, completion: @escaping (Error?) -> Void) {
        
        guard let oktaFileURL = oktaPlistName else {return}
        
        let flow: SessionTokenFlow
        do {
            flow = try SessionTokenFlow(plist: oktaFileURL)
        } catch {
            print("Error creating SessionTokenFlow")
            return
        }
        
        flow.start(with: sessionToken, context: nil) { [weak self] result in
            switch result {
            case .success(let token):
                …
            case .failure(let error):
		// HERE WE ARE RECEIVING “Invalid key data.” error
                self?.handleError(error: error, completion: completion)
                return
            }
        }
    }

What is expected to happen?

start function return success with a valid Okta Token

What is the actual behavior?

start function is returning "Invalid key data"

Reproduction Steps?

Install the app and try to sign-in

Additional Information?

No response

SDK Version(s)

1.3.0

Build Information

No response

[mikenachbaur-okta]

The JWTError.invalidKey error is thrown when the ID token returned doesn't match the key signature from the authorization server. For example, if the kid claim in the ID token isn't found in the list of supported keys returned from the server.

A bug was fixed in version 1.3.1 that caused a problem when loading the key set from the authorization sever, so if you wouldn't mind trying that version out to see if it fixes your problem, I'd greatly appreciate it.

If your problem persists, we could try to troubleshoot the problem further.

[mikenachbaur-okta]

I'm going to close this ticket since we haven't heard back, but if you're still experiencing this problem, please feel free to reopen it.

[ntorrescodigodelsur]

@mikenachbaur-okta, we are experiencing this issue again. We've added an informative message for the user when this error occurs, but we've been checking for the error type assuming it's an object of the OktaError type. It appears that a non-OktaError object is arriving instead

[mikenachbaur-okta]

@ntorrescodigodelsur I've reopened the ticket, since you're still experiencing this problem.

There are three places where this error may occur:

1. When the JWT's signing key ID isn't found within the Authorization Server's keysets.
2. When the token is being validated, and the JWKS keyset object isn't supplied for some reason.
3. When the RSA Public Key data cannot be created for some reason.

Unfortunately it's not clear which code path this error is being thrown from, though there are two likely possibilities:

1. The token was signed with a key that either isn't in the returned from the authorization server, or the Keyset endpoint response is being cached for too long. I recently released a new version 1.4.3 that works around a situation where the URLSession cache may try to cache the keyset data for too long, which could influence this.
2. The key being used might not be an RSA key (which is currently the only supported key type in the SDK).

Hopefully this can help to narrow the problem down. Please let me know if you're able to find out more, and I'd be happy to help figure this out.

[wingsofdoug]

I am also running into this issue, but on a forked branch. I have found this error to not actually be returning from start() in my case but rather deeper inside the library in a stack trace that travels from resume() through the exchange() function. I'm going through a password grant type flow. It is here that the JWK does not match.
I do not have a consistent way to debug this as it is a time problem, but if you run
URLCache.shared.removeAllCachedResponses() then it will resolve the issue.
EDIT: That fork should be up to date with 1.7.1. 1.4.3 did fix some other caching issues we had with some certificate updates.