I am working on a NextJS app where one developer implemented #auth0/nextjs-auth0. We want to EMBED the Lock form within a custom login page (not the redirect method, but the embed method). What are the options for making this happen?
Related
when login using Auth0 Webauth in React-Native it opens the browser for login.
I want to create a smooth login so that the user should not able to experienced whether I logged in using App or Browser jut like a webview anyone any idea?
Just to be clear are you asking if Auth0 supports doing this without a browser? Given that it's likely using OAuth2 or OpenID Connect then the short answer is no.
Further to that WebAuthn is a browser-based Javascript API so by definition would require a browser with these features to be available.
That said, there's probably nothing preventing you from implementing a native WebAuthn-like experience using CTAP2 (the protocol that sits underneath WebAuthn) directly or a platform-specific wrapper around the same.
I’ve been using Auth0 in my React web app. I also have a rule that works with new user sign ups. In my web (React) app, I use the Lock library and everything works fine.
Now, I created a React Native mobile app and because I have a custom login/sign up UI, I had to use the API method as opposed to using an Auth0 library such as Lock, etc.
My SignUp API calls work fine and create new users but my rule is NOT working with API calls. I checked to see if rules apply only to my web app but I don’t see any setting for that so I assume all rules should work for all apps that appear on my dashboard – including my new React Native mobile app.
The rule I created on Auth0 creates and assigns a new my_app_id to the new user. This rule has worked flawlessly with all sign ups coming from my web app which uses the Lock library but it doesn't seem to be firing when a new sign up comes in through the sign up API end point.
Is there anything I need to do so that my rule will work with my API calls?
Rules only run after a successful authentication event. This would not include a successful signup endpoint call, where no credentials are authenticated.
The recommended way to hook to a signup would be through a registration hook.
We have two administrative SPAs that can make easy use of the FusionAuth templated login / verify screens. This is useful as the screens automatically reflect our social logins as those are configured,
The third SPA is carefully designed and places the login fields on a dynamic splash page. I'm considering an attempt to html embed the FusionAuth login panel on our splash page but would need to strip away the nav bar and background container. I think this would be a global change to the FusionAuth UI web layout, forcing the use of embeds in all our apps.
We have FusionAuth running on a subdomain so an embed might not cause much CORS difficulty. Are there any other reasons that embedding the login panel directly from the FusionAuth server into our pages might not be a workable solution?
You can modify the FusionAuth login UI without impacting the administration UI. If you go to Settings -> System -> UI, you will see that the Login UI templates can all be modified.
If you have different login UI elements for different Applications, you can use the variable client_id in the templates to control the layout. This is the OAuth client_id that for the FusionAuth Application. These templates are FreeMarker, so a conditional statement might look like this:
[#if client_id == 'ee31103f-2fc1-4bb5-ba95-ac543693503e']
Embeddable HTML/CSS goes here
[#else]
Standard HTML/CSS goes here
[/#if]
That being said, the OAuth login UI of FusionAuth might not be easily embeddable in your third SPA depending on if you are using an iframe or AJAX. It is still probably a better idea to skin the login UI to match your UI instead and leverage the OAuth login workflow if possible.
The other solution is to use your own login page and then call the FusionAuth APIs to authenticate the user.
We have been exploring adding an embeddable login system. If you want to open a feature request for this, you can add it on our Github Issue tracker here: https://github.com/FusionAuth/fusionauth-issues
Update: It appears Twitter has fixed this issue. Clicking the authorize button now works! Thank you all for the responses.
I have a UIWebView that opens and directs to Twitters Oauth/Authorize webpage. The user signs in with there Twitter details and authenticates the use of our application with there Twitter account. This process worked perfect before the release of Twitter 6.37 iOS application. What happens now is when the WebView detects https://twitter.com/oauth/authorize?oauth_token instead of staying in the WebView it opens the native Twitter application and dies. If you uninstall the Twitter application everything works as usually it staying within the WebView. How can I prevent this from happening? I want to stay within my UIWebView and not automatically open deep links. I have been reading about the new URL deep link changes in iOS 9, but not sure of how to stop them from my application to other native applications. Thanks for any help!
As a workaround, in twitter authentication screen we can use the Go button on iOS typing keypad instead of using the sign in button on web view until twitter fixes.
Please refer the attached screenshot link for clarity.
Screenshot for the workaround
I ran into this issue as well and figured out it was because my authorize endpoint was set to https://twitter.com/oauth/authorize?oauth_token="+oauthToken (I believe this was in the original documentation). If you add api as the subdomain: https://api.twitter.com/oauth/authorize?oauth_token="+oauthToken, it will no longer trigger the deep linking and load the twitter app.
My answer to this via a Xamarin question:
Unless Twitter removes/updates the apps section of "https://www.twitter.com/apple-app-site-association" to allow a bypass or a secondary oauth that is not in the apple-app-site-association file I do not see how you would do it. These files are signed and iOS handles them at an OS level.
I have not played around very much with the continueUserActivity delegate and the NSUserActivity object that is passed to apps launched from UNI links, but I do not see a way for the launched app (i.e. Twitter) to return control to the original app, and at that point the oauth call-chain would be broken anyway....
Unique. Unlike custom URL schemes, universal links can’t be claimed by other apps, because they use standard HTTP or HTTPS links to your website.
Secure. When users install your app, iOS checks a file that you’ve uploaded to your web server to make sure that your website allows your app to open URLs on its behalf. Only you can create and upload this file, so the association of your website with your app is secure.
Via: https://developer.apple.com/library/prerelease/ios/documentation/General/Conceptual/AppSearch/UniversalLinks.html
I would report as an issue (bug?) to Twitter's Dev forum: https://twittercommunity.com
The whole idea is to authenticate App, App Lite, App iPhone, App iPhone Lite with single Box.com App ID and return the user to the right app which redirected to the user to the authorization/authentication web site.
My Conclusion till now leads to using different App Id, because of lack of option to add different Redirect url's and respectively possibility for [box-api] to recognize the right caller application.
Will it work if I try to embed auth url in UIWebView and handle the response from that webView?
We currently don't support this use case, and you'll need separate App IDs