Using generic (custom) connections with Auth0 - oauth

I am trying to use Auth0 to log in to several social media sites at once in a single page app. I have added a generic OAuth2 server to my account for Tumblr, using the instructions here: https://auth0.com/docs/connections/social/oauth2. I have verified that the server was correctly added, and the JSON-P response for my client application is populated with the correct info based on what I added.
My question is, how can I use the JS popup widget to login to this server? I essentially have a couple social logins that are built-in to Auth0 that are working by passing (e.g.) connections: ['twitter'] to the .show() function, and a couple social logins that are not built-in, that I can't seem to wire in correctly to work similarly to the built-in social logins.
In other words, when I use connections: ['twitter'], the popup correctly shows the "Login with Twitter" button. However, when I use connections: ['tumblr'] (where 'tumblr' is the name of the custom connection I made), the popup doesn't show any buttons or even the username/password fields to login to my custom connection. I'm clearly not understanding how this popup is supposed to work with custom connections, so any advice would be much appreciated.

It turns out that Tumblr uses oauth1, not oauth2. So, I was on the right track, but I was just using the wrong eaxmple page. Here is the example page for oauth1 connections: https://auth0.com/docs/oauth1.
You can also then add customizations to the login screen as described here: https://auth0.com/docs/libraries/lock/ui-customization. That will allow you to do what I was looking for in my original question.

Custom OAuth2 connections won't show up on Lock (the UI widget), you have to use your own UI. The library you are looking for is auth0.js (UI-less library) that will handle the auth process for you.
This is likely changing in the next release of Lock.

Related

Google Oauth2 Consent Screen "Allow" button disabled for DELPHI app

Can someone please help me why the button "Allow" in the screen below is disabled? WE are using a Delphi application in order to have user single sign on with google using the TWebBrowser built in delphi to start the process. Here is what our payload looks like: (Is there a way to bypass this check? maybe send other parameters to the url request? or other ideas how can we authenticate google using the client_id..etc. )
We have been reading similar posts in Stackoverflow, but no solutions.
Thanks
https://accounts.google.com/o/oauth2/auth?
client_id=1000217514248-pqeu5oqj3easr************************&
redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob
&response_type=code&
state=995F6663-D8FE-4***************&
scope=openid+email
&code_challenge=0C336C62-1B4E-49F7-*************&
login_hint=test%40test.be
&hd=test.be&
as=S-737348098%3A1615472*****6&flowName=GeneralOAuthFlow
You need to make sure that you are opening the browser window on the users installed browser.
You cant open the consent screen from any type of embeded browser or iframe . You need to open a new window in the users installed browser
I had that same problem before. Google is detecting an old and insecure browser and will not allow the authorization to proceed.
I ended up creating a TCustomAuthenticator descendent class for this. This should work on older versions of Delphi.
It implements a OAuth2 Authenticator:
Allows authorization via externel browser
Uses PKCE flow for added security
Generates new tokens when they expire (using the refresh token)
In the repository there's a Demo app too.
Feel free to use it if you like:
https://github.com/imperyal/delphi-google-oauth2
We stopped using embedded browsers...we used the common Google services in order to have the pop up from default browser in order to login. The current DELPHI version uses Internet Explorer 11 as internal browser, i believe that New versions of delphi have Edge as internal browser which this will not have the disabled button on.

iOS Firebase Auth Domain visible to users

I have searched for solutions to this issue but everything I've found seems to be applicable to a firebase web app, not to iOS implementations.
When verifying a user using firebase phone auth for iOS, I understand the recaptacha is very unlikely to appear. However in the event it does, it creates a webview for the recaptcha like so:
Is there any way for me to hide the myProjectId-12345.firebaseapp.com from the user? It's not very clean or secure I'm afraid. I haven't been able to find anything in the way of documentation on this topic, and most stack overflow answers that solved the issue seem to be applicable to the firebase web sdk only.
Am I missing it somewhere? I have followed the documentation for silent notifications as well, so normally the recaptcha does not appear. From the documentation, "only a very small percentage of users will experience the recaptcha", but I would still like to account for those users.
Set up your domain for Hosting
Step 1: Add domain
From your project's Hosting page, enter the wizard for connecting a
custom domain:
If you have only one Hosting site, click Connect domain. If you have
more than one Hosting site, click View for the desired site, then
click Connect domain. Enter the custom domain name that you'd like to
connect to your Hosting site.
(Optional) Check the box to redirect all requests on the custom
domain to a second specified domain (such that example.com and
www.example.com redirect to the same content).
Click Continue to initiate the validation process.
Step 2: Verify domain ownership
If requested in the Connect Domain setup wizard, verify your apex domain.
Step 3: Go live
In the Connect Domain window of the Firebase console, select Quick
Setup for a new site or Advanced Setup if you already have a site
running on another hosting provider and need a zero-downtime
migration.
Have a look at this for detailed information.

Typo3: FE Login with POST Request to external app server

I recently started getting into Typo3 but now I have to implement something for work and I have no clue where to start.
The requirements:
I have to add a separate page that can only be accessed by frontend
users. (so far no problem)
These frontend users should be able to login with the same password
as they got for their iOS app. (uh-oh)
The separate page should display data from the app. (less of an uh-oh
but connected to the previous point)
After talking to the developer of the app, he made a specific POST request that can be used for the webpage. I am also getting a json-file with the required data that I need to display upon successful login.
My question lies with the login. How do I go about implementing this? I use the extension felogin to provide the login form on the page.
The POST request is looking sort of like this:
https://domain.at/api/queryMediaItems. It needs user and password, declared as user and pwd. In the body there should be a json object with the language, e.g.:
{"language":"de-at"}
You need to implement a SSO (SingleSignOn) as your users need to identify against the iOS-app.
This might give you a concept.
You also can look inside the code of some extension

Redirect user using NetworkExtension framework

I have an application that uses NEFilterProvider API to filter urls (allows/blocks browsing). ControlProvider and DataProvider extensions created.
So for this point I can block/allow certain urls.
I wonder if there is a way to implement redirection to custom url using NetworkExtension ?
According to NEFilterDataProvider:
If the Filter Data Provider chooses to block the web page, then a special “block” page is displayed in the WebKit browser object informing the user that their attempt to access the content was blocked. The Filter Data Provider can choose to add a link to this block page, giving the user the option of requesting access to the content.
There is no other way to redirect user besides a link from "block" page. Neither url nor page content could be changed using NEFilterProvider API. The best solution for redirection would be a VPN connection. You can find example here.

SalesForce canvas app oauth web server flow with minimal user interaction

So I'm weighing up the pros/cons of the different auth mechanisims for a SalesForce Canvas application.
First, a little background. I've got an existing web app - let's call it "myapp". I setup a VisualForce tab containing a VisualForce page which embeds my canvas app by the following approach:
<apex:page>
<apex:canvasApp applicationName="___________" />
</apex:page>
I first implemented access via the signed request method, which was great, as the user only had to accept my app's permissions on first access, and subsequent attempts to access my canvas app could jump right in to myapp homepage.
From reading this article about packaging canvas apps for different SalesForce editions, signed request method has a limitation:
Most typical Group and Professional Edition customers are not going tobe able to use your Signed Request Connected App unless they upgrade to EE or higher or purchase these features as an add-on.
So I decided to switch to the oauth workflows.
Looking at the user agent oauth flow documentation, it says:
The user must always approve access for this authentication flow. After approving access, the application receives the callback from Salesforce.
This is also not desirable, however the web server oauth flow does not have that requirement - once a user accepts the app's permission requirements, they don't need to be prompted to do that again. It also makes things like adding a "Login with SalesForce" option on myapp's login page super easy to add in.
So I setup the web server oauth flow, and have everything functioning well, and as an added benefit added a "Login with SalesForce" option to my login page - great.
Next step was to set the canvas app in the VisualForce tab up to kick off the web server oauth flow.
The problem I want to solve:
I want to use the web server oauth flow to gain access to the homepage of myapp from that VisualForce tab, with as few user interactions as possible in the process.
Base setup
To initiate the oauth flow, I've setup a URL with the following logic in there to make it simple to craft links that kick off the process from elsewhere. This is used from each of the below examples, and is referenced by links to /salesforce/oauth/......
// Allow links to this page to specify "state" and "prompt" paramaters.
$state = isset($_GET['state']) ? $_GET['state'] : 'login';
$prompt = isset($_GET['prompt']) ? $_GET['prompt'] : '';
// Canvas app contextual information provides the right SalesForce endpoint domain, so provide a way for that to be passed in here, or fallback to standard login.salesforce.com for other workflows.
$authDomain = isset($_GET['authDomain']) ? $_GET['authDomain'] : 'https://login.salesforce.com/services/oauth2/authorize';
$url = $authDomain.'?'.http_build_query(array(
'response_type' => 'code',
'client_id' => 'XXXXXXX_MY_APP_CLIENT_ID',
'redirect_uri' => 'https://'.$_SERVER['HTTP_HOST'].'/salesforce/authorize/',
'state' => $state,
'prompt' => $prompt,
));
header('Location: '.$url);
die;
Failed attempt 1
Using the javascript canvas sdk, redirect the canvas app to initiate my web server oauth flow:
location.href = '/salesforce/oauth?authUrl='+encodeURIComponent(Sfdc.canvas.oauth.loginUrl())+'&state=canvas';
I ran into two problems with this approach:
The canvas app looses the contextual information provided by the #query fragment in it's URL.
X-Frame-Options header of the SalesForce page which has the accept/decline permissions prevent it from displaying within an iframe, even on SalesForce domains.
I feel this would be the best way to accomplish my goal if these issues could be overcome.
I actually did an experiment which resolves issue #1 by loading that URL in another iframe, within my canvas app, and if I'd already accepted myapps permission requirements that worked flawlessly, however I was still stuck with issue #2 when the permissions screen popped up and the whole process failed to complete.
Current solution
I've made the initial canvas app page include a button to click, which opens the web server oauth flow in a new window where it completes successfully. Upon completion, the canvas app iframe is redirected to my app homepage.
I'm unhappy with this, because every time I click on my VisualForce tab, there's a step in there requiring the user to click a button, and a new window pops up to run the oauth workflow. It closes itself automatically with no extra user interaction if the user had already accepted the app permissions in the past, or prompts them to accept if they hadn't yet, and then closes itself.
If I'm stuck with this solution it's not the end of the world - we'll make that button into a splash screen with some marketing crap in there and a big obnoxious "Continue to MyApp" button somewhere.
The question (...finally)
Is there some way I can remove that necessary step of clicking the button every single time the canvas app is loaded, but continue using the web server oauth flow here? (remembering I don't want to use the user agent oauth flow because that has a similar requirement of accepting the permissions every time the user accesses it anyway).
That extra step is particularly annoying when the canvas app is being embedded within a SalesForce account or contact screen - as it stops my app from loading and displaying data to my users until the user clicks on the button.
Either I don't get it, or that's really simple. You need to use oAuth immediate parameter:
immediate — Determines whether the user should be prompted for login and approval. This parameter is optional. The value must be true or false if specified. Default value is false. Note the following:
If set to true, and if the user is currently logged in and has previously approved the client_id, Salesforce skips the approval step.
If set to true and the user is not logged in or has not previously approved the client, Salesforce immediately terminates with the immediate_unsuccessful error code.
Source: 1, 2
The only catch is the last part: you will receive error if user hasn't authorized your app yet. In my experience with oAuth it's really easier to use Javascript to run your requests from the client's browser itself. You can fire off immediate = true request, and right after it immediate = false in case first one failed. Then you send the access_token to your app by creating third request – to your own server.

Resources