webAuth.authorize function doesn't behave as expected
Checklist
- [X] The issue can be reproduced in the react-native-auth0 sample app (or N/A).
- [X] I have looked into the Readme, Examples, and FAQ and have not found a suitable solution or answer.
- [X] I have looked into the API documentation and have not found a suitable solution or answer.
- [X] I have searched the issues and have not found a suitable solution or answer.
- [X] I have searched the Auth0 Community forums and have not found a suitable solution or answer.
- [X] I agree to the terms within the Auth0 Code of Conduct.
Description
According to the documentation, if we have a valid session, when using the webAuth.authorize function and not passing in a additionalParameters: { prompt: ... } value, the modal should close right away and the user would automatically be logged in, as the cookie will still be there.
I've tried this behaviour, but it doesn't work as expected, I seem to be prompted every time with the login page, regardless of not passing the prompt: 'login' additionalParameters and having a valid session.
I have verified that we're indeed able to get authenticated if using the prompt: 'none' without displaying the login page, so, this does seem like a bug.
Reproduction
- Login via
auth0.webAuth.authorize(..., scope, audience, etc...)- _tried both with email, or SMS connections, no difference) - Note, we're not passingadditionalParameteres - You'll receive the
Credentialsresponse. - Save it, and so on, with credentials manager.
- Trigger again the
auth0.webAuth.authorize(..., scope, audience, etc...)- You'll be shown theloginpage again, although a session (hence, cookies) was existing. - Note, we're not passingadditionalParameteres
Additional context
No response
react-native-auth0 version
3.1.0
React Native version
0.71.14
Expo version
48.0.21
Platform
Android, iOS
Platform version(s)
macOS: macOS Sonoma 14.3.1; Xcode: 15.2
Hello,
Adding a reply here as I've been suggested by the Auth0 Email Support ticket 02340685, ref: ref:!00D370JYbE.!500Ho01MhogC:ref.
I've been asking to clarify whether I was using an ephemeral session or not; that's not the case, ephemeralSession is not passed since we want to achieve SSO, and we don't mind showing the native alert box (needed since using ASWebAuthenticationSession).
@Noitham are you using auth0-react on the website side? We have seen similar issues before where the web counterpart was not setup properly. Can you share how you have setup the hooks here without sensitive data?
Hello, @poovamraj, sorry for the late reply.
I've created a reproducible example project:
https://github.com/Noitham/auth0-sso-issue
I've added a Readme with the issue description as well as how to get the project running.
The issue seems to be related to the usage of the sms connection. Seems that in that case, the authorize function doesn't behave as expected in terms of the prompt, since it's always prompting for authentication although having a valid ongoing session.
Hello @poovamraj, is there any update on the issue?
Have you been able to reproduce it with the example?
Probably the same
No updates on this issue?
@david-shiko @Noitham thanks for your patience here. We will plan to address this in our next major release. We are tentatively planning to begin work on this by mid December.
Hello @brth31, Thanks for getting back to us on this issue. We're looking forward to hearing news about it.
Hi @Noitham , This is an intentional behaviour. If aconnection param is passed and the prompt param is not none then it ignores the session cookie and redirects the user to the IDP, in this case the passwordless email / sms connection.
@Noitham Any chance the feedback from @pmathew92 worked for this issue? Would you need any more help with this?
Hello @pmathew92 @poovamraj,
Please, refer to my reproducible example repository: https://github.com/Noitham/auth0-sso-issue Where the issue has been described.
Also, we're in connection with the Auth0 team via email at the moment and I wonder if @poovamraj / @pmathew92 are you guys also working for Auth0?
@pmathew92 - There's no place in the documentation specifying a connection parameter will invalidate the session.
If no specifying a connection, we'll display the Email/Password login as well as the social logins as alternatives, but not the phone number, which is the kind of authorization that we want.
And then, in regards to the prompt param, I've also described the different behaviours if havinga prompt specified as none or non-specified (undefined).
At the moment this is an ongoing bug for us. So far, the "solution" offered by the team has been creating a new application within our Auth0 project where we only configure the Passwordless SMS connection, but we still need to try it out and the challenges that it will bring it:
- Needing to setup a new Auth0 client in our application
- Having to deal with two different tokens from two different applications?
- Which one should be used? What are the effects of this?
@Noitham I am the old maintainer for this SDK now in a different team. @pmathew92 is the new maintainer for the SDK. Both of us are with Auth0 :)
The example repo is amazing and we are going to look into it to understand this issue. I am fairly confident this is a configuration that isn't working properly somewhere. But let us get back to you soon on this :)
@Noitham Any reason you are doing Step 3. when you have the credentials already? Is it a kind of step up challenge to authorize the user with passwordless connection?
@poovamraj - Alright, great to know you guys then :)
Yes, about the 3. step on the OP message in this issue, feel free tho disregard it, it doesn't have any effect to store or not on credentials manager.
There's also steps description in the example repo: https://github.com/Noitham/auth0-sso-issue
@Noitham the steps in the repo make sense. Any reason Login (SMS) is clicked again once authentication is successful? As you mentioned the work around is with 2 clients. If there is more, the Auth0 team you are in contact will definitely help you with high priority.
Would it be okay to close this issue and use the thread you already have for the conversation?