We Keep Coding

What redirect URI should I use for an authorization call used in an Electron app?

I have a basic Electron app doing nothing special, based on sample starter projects.
For my main window, I am loading in a URL as a GET request to an API endpoing
loginWindow.loadURL('https://apiwebsite.com/api/v1.0/authorize?secret_id=my_secret&redirect_uri=<???????>')
As a part of my GET request to this API endpoint I have to send a return URI. This actually works fine, in that I can get the API to return and load the URI that I specify. However I do not know what URI to specify to get this to come back to somewhere within my app where I can read the response and proceed.
I am used to web development but Electron is new to me. I do not follow how I can submit a return URI in this instance. What would be it be? Would it change for local development vs a packaged application?
Is there a better way to do this?

OAUTH FOR DESKTOP APPS
OAuth for desktop apps recommends these 2 key behaviours:
Login via the system browser so that your app never sees the user credential
Use Authorization Code Flow (PKCE) since your app is a public client
This typically leads to one of these solutions:
Loopback based redirect URI such as http://127.0.0.1:8000/callback
Private URI scheme based redirect URI such as x-mycompany-desktopapp:/callback
As you are finding, a standard HTTP based internet redirect URL will not work for a desktop app unless you use older (deprecated) web view solutions.
RESOURCES OF MINE
It is tricky flow to implement, though my blog has a couple of Electron code samples that you can easily run from your local PC to see what both solutions look like:
Initial Desktop Code Sample, using the Loopback Solution
Final Desktop Code Sample, using the Private URI Scheme Solution
My samples are quite deep, but hopefully some of this is useful for your own solution ...

How to support HTTP protocol in Electron/Firebase App

I'm trying to user firebase authentication (saml) within my Electron app. I have read that Electron isn't "officially supported", however I've also encountered some threads that indicate people have gotten it to work. My issue is when using firebase.auth().signInWithRedirect (or signInWithPopup), I get the error:
code: "auth/operation-not-supported-in-this-environment"
message: "This operation is not supported in the environment this application
is running on. "location.protocol" must be http, https or chrome-extension and
web storage must be enabled."
Google turns up this tips and tricks article which suggests just using a hosted URL:
Third, OAuth requests need to have a verifiable origin, which can be whitelisted in the Firebase Console. This requires the current Electron browser window to use the http or https protocol, and not file. That means the current window contents should be loaded with browserWindow.loadURL and not browserWindow.loadFile, and the url must be an http or https url, not a file:// url. This generally requires a hosted page somewhere that gets wrapped into the Electron window.
This will probably work, as just running the app locally on the angular dev server works by simply using:
mainWindow.loadURL('http://localhost:4200');
I don't want to do this because having a hosted page lessens much of the appeal of having a native app.
I could make this work in by just having a local Node/Express instance serve the app locally using get-port to find a free port to run the app there. I haven't really seen any examples showing this. There are a few Stackoverflow questions on getting it to work, but nothing that makes me think it is an acceptable production-level solution.
Is a local Express server an acceptable way to circumvent this error, or is there currently a better solution?
Note: The package recommended in this answer is not published by Firebase and anyway doesn't look like it supports SAML auth.

I had to do something very similar but with Auth0 instead of Firebase.
What I had to do was make two Browser Windows, where the first one is strictly an authentication Browser Window while the second one is the actual main App Browser Window.
Auth0 has the same restrictions of whitelisting only http/s protocols, so in the authentication Browser window, I load the Auth0 sign in URL via localhost (it’s a hosted URL in Auth0 itself). I then take the credentials (access token and refresh token) from that redirect/Oauth process and store them locally for the time being (use Keytar, SafeStorage, FS modules, whatever; I chose Keytar).
Then my authentication Browser Window closes itself and launches the main, app Browser Window.
From here onward, I have to reference my stored access token and refresh tokens from my storage location and use those in all other calls.
So, for instance, I have some API library modules I made for myself that use Axios. So I bring the saved access token into all of my Axios calls. Works like a charm.
So, in summary: I had to use two different Browser Windows and persist credentials locally for later use in the main Browser Window.
Check out Auth0’s guide on using Electron for authentication; I think you’ll find that many concepts carry over for Firebase and other providers.

i've successfuly implemented firebase email ver in my app, it is more feasible to load .html file rather than load a page from url as users can exploit the the url by sending fake data. but with oauth it is not possible,firebase create webapp you can create a html file it should contain api keys, host url etc and host it locally in android file://android_assets/filename.html this works fine even offline i dont know properly about
electron

How to test Pinterest SDK locally?

I'm testing out the Pinterest SDK on my local machine. The problem is, I need a secure server in order to test the API (they only allow Redirect URIs with a HTTPS prefix).
Every time I try to login to the Pinterest application it throws the error:
{"status": "failure", "message": "You are not permitted to access that resource.", "code": 7, "data": "The provided redirect_uri http://localhost:3000/ does not match any of the registered redirect URIs."}
Is there any way I can test via HTTPS locally?

If you are using Create React App you can start the development server in HTTPS, see https://github.com/facebookincubator/create-react-app/blob/master/packages/react-scripts/template/README.md#using-https-in-development

You can't. Pinterest demands that you have https link.
I tried using ngrok to convert my localhost link to an https link for testing. But it was throwing some errors, so skipped it. You can try it out though
But if you wish to have a temporary setup to work with the APIs, lets say to write down functions to process information you get from APIs, which was my requirement, then you can follow what I did. May not be the best option, but I could get my job done.
I hosted a basic app on firebase. Firebase provides some sample apps which you can use as base app if you want.
Just get the link of the hosted app and add it in your app page in Pinterest.

How to use OAuth with Github in a Safari extension

I'm new to browser extensions. i'm trying to create a Safari extension that allows me to perform basic tasks in my Github account (Create a repo, for example). I'm doing it mostly to learn how to develop extensions while practicing my JS.
The issue is that in order to connect to Github I want to use OAuth, but I have no clue of how to do that. I have googled to see if I can find a library that I can use without any results. The main problem is that when trying to register my "application" with Github, I have no idea of what URL to provide for the main application and the callback, since it is not a web application what I'm developing; it's an extension.
Does anyone have any experience with this and can give me a tip on how to proceed? What URL should I use to register with Github? Is it possible to use OAuth from an extension at all? Is there a library, SDK, anything that can help do this job?
If this question can be broaden to any browser, just tell me and I will change the title to help others in the same situation.
Thanks to all for helping.

I have used OAuth in a Safari extension and you're welcome to look at my code for an example (see link below), but this JS library for Github might have all you need. I haven't used it, but it looks nice, and it supports "personal access tokens", which I take to be a kind of OAuth token for Github that doesn't require specifying a redirect URI.
My Safari extension (Github link) uses OAuth 2.0 to talk to the Pocket API. It doesn't use a library. For the redirect URI, I use the same URL as that of the page that initiates the whole authorization process, but with "?status=done" appended to it. The page's script checks its URL, and if the URL ends in that string, then it knows that the page was loaded by the authorization window and so it can proceed with getting the access token.
One thing you should be mindful of when using OAuth in any kind of client-side application, such as a browser extension, is that your OAuth app token will be exposed to the users of your app. Even if you encrypt it in the app or retrieve it from a server over https, a user can use the browser's built-in JS debugger to get the token, because you have to decrypt it at some point in order to use it. If someone steals your token, they can use to trick people into authorizing their nefarious app that pretends to be yours. It's up to you to decide whether this risk is tolerable. The only way to avoid this risk is to have your own server-side app that communicates with the third-party API, and your extension communicates with that. But then someone could learn from your extension's code how to talk to your server-side app, so I'm not sure whether that really buys you anything.

Secure way of persisting an auth token in a single page js application

Our scenario:
Our solution consists of an MVC app which serves a single page javascript application, and an Asp.Net WebAPI app which is intended for use both as a standalone api and as a source of data for the SPA.
We have set everything up so that the two apps will share auth tokens and membership, so if we are logged in to the SPA then the same formsauthentication cookie will also allow us access to the API.
This works fine if you make API requests in the browser address bar, but not through AJAX. We have followed examples of setting up basic authentication using Thinktecture and if we hardcode username\password as an authentication header for our ajax calls then this works fine also.
My question is however, what is the correct way of persisting these details on the client side? Our only real solution so far would be to send down the base 64 hash of the username\password as part of the initial load of the SPA and then pull this out when needed. This seems insecure however.
So basically, just wondering what the 'correct' approach is in this situation... are we close or is there another approach that we have overlooked?
Thanks!

We're using the session token support from Thinktecture.IdentityModel and then making the token available to the client via a dynamically generated script.
Full details at http://ben.onfabrik.com/posts/dog-fooding-our-api-authentication
I also published a sample application demonstrating these concepts at https://github.com/benfoster/ApiDogFood.