Implement WebAuthn authenticator support in DirectAuth

[mikenachbaur-okta]

Adds support for WebAuthn factors within DirectAuth. This also improves upon supplying token parameters, and defining the desired grant type, based on the supplied factor combined with the current status of the user's authentication.

Note: the JSONValue class and tests were taken from okta-idx-swift. An update to that SDK will made to consume JSONValue from AuthFoundation.

[mikenachbaur-okta]

Note: The version of swiftlint updated on Github Actions' runners, so this also includes some changes to address lint warnings.

[mikenachbaur-okta]

Note: This class came from the okta-idx-swift repo, which will be updated to consume AuthFoundation for this feature in another PR.

[santhoshramaraju-okta]

will webauthn in MFA use case be added separately? if so this grant type will probably change to urn:okta:params:oauth:grant-type:mfa-webauthn and that will create a problem with resuming the flow using secondary factor similar to the issue #175.

[mikenachbaur-okta]

No, according to the spec, the grant-type is the same for both primary auth vs MFA auth. However, you did help me point out one gap, where the list of challenge_types_supported will return urn:okta:params:oauth:grant-type:mfa-webauthn when initiating a WebAuthn challenge as an MFA factor. So I need to make sure that's supported in this code.

[santhoshramaraju-okta]

can you add the check for mfaToken here too to determine the right grant type to fix the issue with push factor number challenge?

[mikenachbaur-okta]

I'll do that as a separate PR, since I didn't want to bloat this one any more than it already has.

[baksha97]

In a user application, we might choose to favor prioritizing removal from the device and opting to fire off a background task for revocation. We wouldn't want any circumstance truly where the user can't "sign out" from a device.

The way this is written, if you remove the token first and then try to revoke it, it will throw an error since the removal portion will fail since it'll already have been removed, correct?

Is it possible to de-conflate the revocation to be a separate function that doesn't attempt removal?

[mikenachbaur-okta]

@baksha97 If the revoke is unsuccessful, the developer could still call remove(). However, if the revoke operation failed due to a network timeout/offline error, the token will still be valid on the server, and removing it will prevent the app from being able to revoke it in the future.

For example, you could do the following:

do {
  try await credential.revoke()
} catch {
  // Check to see if the error is recoverable
  if shouldRemoveTheToken {
    try credential.remove()
  }
}

[rajdeepnanua-okta]

Does this need currentStatus as a function parameter? I don't see that being used in this function

[mikenachbaur-okta]

The grantType property/function is a property of the AuthenticationFactor protocol, which is shared by both Primary and Secondary factor types. The SecondaryFactor uses the current status to determine whether or not the grant type should be a primary authentication, or MFA.

For example, in this line the code checks to see if the current status is associated with an MFA Token, which changes which grant type should be used.