Skip to content

fix(MFAClient): Add challengeType parameter to challenge method - #1263

Open
Dodothereal wants to merge 1 commit into
auth0:masterfrom
Dodothereal:fix/1262-mfaclient-challenge-assumes-challenge-ty
Open

fix(MFAClient): Add challengeType parameter to challenge method#1263
Dodothereal wants to merge 1 commit into
auth0:masterfrom
Dodothereal:fix/1262-mfaclient-challenge-assumes-challenge-ty

Conversation

@Dodothereal

@Dodothereal Dodothereal commented Jul 18, 2026

Copy link
Copy Markdown

fix(MFAClient): Add challengeType parameter to challenge method

Summary

Fixes MFAClient.challenge() method to accept an optional challengeType parameter, allowing proper OTP authentication challenges instead of hardcoding "oob" for all authenticator types.

Previously, the challenge method always used "oob" as the challenge_type, which breaks OTP (one-time password) authenticator flows that require "otp" as the challenge_type. This change adds backward compatibility by making the parameter optional with a default value of "oob".

Fixes #1262

Changes

  • Modified MFAClient protocol to add optional challengeType parameter to challenge(with:mfaToken:challengeType:) method
  • Updated Auth0MFAClient implementation to use challengeType ?? "oob" for the challenge_type payload
  • Added documentation and usage examples for both OOB and OTP authenticators
  • Added unit test to verify OTP challenge type is properly transmitted
  • Updated EXAMPLES.md with guidance on using challengeType parameter for OTP authenticators

Testing

  • Added unit test testMFAChallengeWithOTPType() that verifies the challengeType parameter is correctly passed in the request payload
  • All existing tests continue to pass, confirming backward compatibility
  • Manual verification that the change maintains existing OOB functionality while enabling OTP support

AI assistance disclosure

This contribution was produced by an autonomous AI coding agent (Claude Code) that @Dodothereal operates and monitors. @Dodothereal is accountable for it, will address review feedback promptly, and will close this PR immediately if this kind of contribution is unwelcome in this project. Commits carry an Assisted-by: Claude Code trailer.

Summary by CodeRabbit

  • New Features

    • Added support for initiating MFA challenges with a specified challenge type, including OTP.
    • Existing challenges continue to default to out-of-band (OOB) authentication when no type is provided.
  • Documentation

    • Added OTP challenge examples for completion-handler, async/await, and Combine usage.
  • Tests

    • Added coverage validating OTP challenge requests and responses.

- Add optional challengeType parameter to MFAClient.challenge() method
- Allow specifying 'otp' for OTP authenticators instead of hardcoded 'oob'
- Maintain backward compatibility with default 'oob' behavior
- Update documentation with usage examples for both OOB and OTP authenticators
- Add unit test for OTP challenge type
- Update EXAMPLES.md with OTP authenticator usage examples

Fixes issue where MFAClient.challenge assumed challenge_type should be 'oob', breaking OTP authentication
@Dodothereal
Dodothereal requested a review from a team as a code owner July 18, 2026 12:32
@coderabbitai

coderabbitai Bot commented Jul 18, 2026

Copy link
Copy Markdown

Review Change Stack

📝 Walkthrough

Walkthrough

The MFA challenge API now accepts an optional challengeType, uses it in requests, defaults to "oob", and documents and tests OTP challenge usage across supported calling styles.

Changes

MFA challenge type support

Layer / File(s) Summary
Challenge contract and request payload
Auth0/MFA/MFAClient.swift, Auth0/MFA/Auth0MFAClient.swift
The challenge API accepts an optional challenge type, and request payloads use the supplied value or default to "oob".
OTP validation and usage examples
Auth0Tests/MFA/Auth0MFAClientTests.swift, EXAMPLES.md
Tests verify an OTP challenge request and response, while examples cover callback, async/await, and Combine usage.

Estimated code review effort: 2 (Simple) | ~10 minutes

Suggested reviewers: nandanprabhu

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly summarizes the main change: adding challengeType to MFAClient.challenge.
Linked Issues check ✅ Passed The changes add configurable challenge_type support and OTP coverage, matching issue #1262.
Out of Scope Changes check ✅ Passed The docs, examples, and test additions all directly support the MFA challengeType change.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@Auth0/MFA/MFAClient.swift`:
- Around line 132-133: Add a public MFAClient protocol extension with the
original two-argument challenge(with:mfaToken:) method, delegating to the
existing three-argument overload with challengeType set to nil, so existing SDK
callers remain source-compatible.

In `@Auth0Tests/MFA/Auth0MFAClientTests.swift`:
- Around line 342-350: Update testMFAChallengeWithOTPType to follow the
repository’s established testing standard: use UpperCamelCase constants
(ClientId, Domain, AuthenticatorId, MfaToken), place the behavior in the
appropriate QuickSpec subclass using describe/context/it, and use
StubURLProtocol or NetworkStub for network setup instead of MockURLProtocol; if
the repository has migrated to Swift Testing and MockURLProtocol, update the
path instructions and at minimum correct the constant names.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 128b4042-72cc-448e-8817-6f7aebbca67e

📥 Commits

Reviewing files that changed from the base of the PR and between ccfe1b0 and 255d66c.

📒 Files selected for processing (4)
  • Auth0/MFA/Auth0MFAClient.swift
  • Auth0/MFA/MFAClient.swift
  • Auth0Tests/MFA/Auth0MFAClientTests.swift
  • EXAMPLES.md

Comment thread Auth0/MFA/MFAClient.swift
Comment on lines 132 to +133
*/
func challenge(with authenticatorId: String, mfaToken: String) -> any Requestable<MFAChallenge, MfaChallengeError>
func challenge(with authenticatorId: String, mfaToken: String, challengeType: String?) -> any Requestable<MFAChallenge, MfaChallengeError>

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 Functional Correctness | 🔴 Critical | ⚡ Quick win

Retain source compatibility for existing SDK callers.

Adding challengeType: String? to the protocol method signature without retaining the original signature removes the two-argument method. Because Swift protocols do not support default parameter values, any existing consumer code calling Auth0.mfa().challenge(with: "...", mfaToken: "...") will fail to compile due to a missing argument.

To prevent breaking existing callers, please provide a default implementation of the original signature via a protocol extension.

🛠 Proposed protocol extension (append to the end of the file)
public extension MFAClient {
    /// Initiates an MFA challenge for an enrolled authenticator.
    ///
    /// - Parameters:
    ///   - authenticatorId: The ID of the enrolled authenticator.
    ///   - mfaToken: The MFA token received from an authentication error when MFA is required.
    /// - Returns: A request that will yield an MFA challenge.
    func challenge(with authenticatorId: String, mfaToken: String) -> any Requestable<MFAChallenge, MfaChallengeError> {
        return challenge(with: authenticatorId, mfaToken: mfaToken, challengeType: nil)
    }
}
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@Auth0/MFA/MFAClient.swift` around lines 132 - 133, Add a public MFAClient
protocol extension with the original two-argument challenge(with:mfaToken:)
method, delegating to the existing three-argument overload with challengeType
set to nil, so existing SDK callers remain source-compatible.

Comment on lines +342 to +350
@Test
func testMFAChallengeWithOTPType() async {
let clientId = "testClientId"
let domain = "test.example.com"
let authenticatorId = "testAuthenticatorId"
let mfaToken = "testToken"
let expectedURL = URL(string: "https://\(domain)/mfa/challenge")!

let request = Auth0.mfa(clientId: clientId, domain: domain, session: makeMockSession()).challenge(with: authenticatorId, mfaToken: mfaToken, challengeType: "otp")

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win

Align test with path instructions for Quick/Nimble, NetworkStub, and constant naming.

This new test deviates from the repository's path instructions in a few areas:

  1. Test Constants: Constants must use UpperCamelCase (e.g., ClientId, Domain, AuthenticatorId, MfaToken) instead of camelCase.
  2. Test Structure: Behavior must be organized using describe / context / it blocks (Quick/Nimble) rather than @Test (Swift Testing).
  3. Network Stubbing: All network interactions must use StubURLProtocol / NetworkStub instead of MockURLProtocol.

As per path instructions:

  • "Test constants must use UpperCamelCase (e.g. AccessToken, ClientId, Domain)."
  • "Every spec file must be a QuickSpec subclass named <Subject>Spec" and behavior organized with describe / context / it.
  • "All network interactions must use StubURLProtocol / NetworkStub".

(Note: If the repository has recently migrated to Swift Testing and MockURLProtocol, please update the path instructions to reflect the new standard; otherwise, please update the test constants at a minimum to align with the style guide.)

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@Auth0Tests/MFA/Auth0MFAClientTests.swift` around lines 342 - 350, Update
testMFAChallengeWithOTPType to follow the repository’s established testing
standard: use UpperCamelCase constants (ClientId, Domain, AuthenticatorId,
MfaToken), place the behavior in the appropriate QuickSpec subclass using
describe/context/it, and use StubURLProtocol or NetworkStub for network setup
instead of MockURLProtocol; if the repository has migrated to Swift Testing and
MockURLProtocol, update the path instructions and at minimum correct the
constant names.

Source: Path instructions

@NandanPrabhu

Copy link
Copy Markdown
Contributor

Hi @Dodothereal thanks for raising the PR. Could you please verify the commit signatures and also rebase the branch with the latest master branch

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

MFAClient.challenge assumes challenge_type should be oob breaking totp authentication challenging

2 participants