Rules not running in Passwordless flow

We want to switch from WebAuth passwordless to native Passwordless thanks to recent addition in iOS SDK (v1.20). But during the login process the rules are not fired.

The flow in the app is the following:

  • User creates an unverified account
  • In Profile settings in app user taps “verify” which opens passwordless flow
  • ID token is enriched with some additional parameters (including the userId from parameters) using Rules
  • The enriched ID token is sent back to the app, which unlocks functionalities that require a user’s e-mail.

The configuration described below is an exact copy of the config passed to WebAuth (parameters, clientID, scope, audience…)

Our invocation code:

static func startPasswordless(userId: String?, deviceToken: String? = nil,
                              email: String, completion: @escaping EmptyRequestResultBlock) {

    let optionalParameters: [String: String?] = [
        "prompt": "login",
        "platform": "ios",
        "locale": Locale.current.languageCode,
        "countryCode": Locale.current.regionCode,
        "deviceToken": deviceToken,
        "userId": userId
    ]

    let unwrappedParameters: [String: String] = optionalParameters.compactMapValues { $0 }

    Auth0
        .authentication(clientId: Auth0Configuration.shared.clientId, domain: Auth0Configuration.shared.domain)
        .startPasswordless(email: email, type: .Code, connection: ConnectionType.email.rawValue,
                           parameters: unwrappedParameters)
        .start { result in
            DispatchQueue.main.async {
                switch result {
                case .success:
                    completion(.success)
                case .failure(let error):
                    completion(.failure(error))
                }
            }
    }
}

static func sendOTP(_ otp: String, for email: String,
                    completion: @escaping ((RequestResult<Credentials>) -> Void)) {

    let scope: String = [
            "openid",
            "email",
            "profile",
            "read"
        ].joined(separator: " ")

    Auth0
        .authentication(clientId: Auth0Configuration.shared.clientId,
                        domain: Auth0Configuration.shared.domain)
        .login(
            email: email,
            code: otp,
            audience: Auth0Configuration.shared.userInfoEndpoint,
            scope: scope)
        .start {
            switch $0 {
            case .success(let credentials):
                completion(.success(credentials))
            case .failure(let error):
                completion(.failure(error))
            }
    }
}

We’d love to see (if possible, record) a demo of this behavior, and talk to you more about what’s happening. Can you reach out to me at chip.johnson at auth0 dot com to get a Zoom meeting scheduled?

Awesome, sent you an email :slight_smile:

1 Like

Perfect! Let other know what was failing here

1 Like

Hi @Chipadeedoodah :slight_smile: Do we have any updates on that one?

I’ll ask @andres.aguiar to weigh in, his team was exploring this as a possible bug in the login code.

Hi @andres.aguiar :slight_smile: Could you share some updates?

Cześć @aniasuchanecka! I’m gonna ping Andres in our internal chat!

1 Like

Andres is still waiting for some answers from the engineering team. He’ll update you as soon as he have news to share!

Thanks a lot @konrad.sopala :slight_smile: Me and @kacperCz, we’re really looking forward to it

1 Like

Sure! Will let you know once we have something to share!

@aniasuchanecka, @kacperCz we tried to reproduce it but were not able to. I’ll follow up with you directly.

BTW, meanwhile, can you try the same flow but without enriching the ID token and see if it works?

Thanks

1 Like

Let us know what was the reesult once you have a chance to test it

1 Like

We found the issue - our rule had a line that checked the context.request.query:

function (user, context, callback) {
    if (context.request.query) {
          var valueFromParams = context.request.query.mySuperSecretValue
          ...
    }
}

which contained the parameters in the WebAuth flow, but for native solution the same data appeared in the body property of the context.

Additionally, the parameters were sent in the startPasswordless function of the SDK instead of login . Passing them in login made them available in the context.request.body.

2 Likes

Perfect! Glad to hear that! And thanks a lot for sharing with the rest of community!

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.