Google OAuth Credentials Redirect URIs problems - xamarin.forms

I have an app in xamarin forms, and I need to implement Google authentication. In my Google API, I have OAuth credentials using Web Application.
The problem is in the Authorized redirect URIs: when I configure the URI using the https, I can choose what account to log in to. After choosing the one I want, I get this error:
Seeing some Youtube videos, I´ve seen that I need to use HTTP instead of HTTPS, but when I try to use this way, I get this error BEFORE I get the Google user´s accounts lists:
So I´m sticking in it and can´t authenticate the user.
I´m using Xamarin Forms, and on the app, there´s no exception thrown.

The redirect URI (where the response is returned to) has to be registered in the APIs console, and the error is indicating that you haven't done that, or haven't done it correctly.
Go to the console for your project and look under API Access. You should see your client ID & client secret there, along with a list of redirect URIs. If the URI you want isn't listed, click edit settings and add the URI to the list.
Note that updating the google api console and that change being present can take some time. Generally only a few minutes but sometimes it seems longer.

Related

Can't get Code from Azure Active Directory from Post because of redirect

I need assistance with a company website I'm working on that should be linked up with Azure Active Directory. I have read those Azure Active Directory Docs. Our cloud team have already setup Azure Active Directory on the Azure Portal and when users including myself try to access the page they are brought to a Microsoft Login Page. Our cloud team have fulfilled Step 1 of registering our app on Azure. And this process of logging into Microsoft fulfills Step 2 of Authorization. The problem here is although the users are able to sign in through Azure active directory, once they sign in and come back to the webpage, we are unable to get the code that Azure generates.
This example Authorize link from the docs shows me the correct process for authorization.
https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=6731de76-14a6-49ae-97bc-6eba6914391e&response_type=code&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F&response_mode=query&scope=offline_access%20user.read%20mail.read&state=12345
This link will send you to Microsoft Login page and then after you sign in, it will redirect to the specified redirect_url and it will provide the code in the query parameters. I can see it in the URL bar.
My company's app authentication currently doesn't work like this. We are able to have the user sign in and get redirect back to our page. But the redirect_url for our app is www.ourwebsite.azuresites.com/.auth/login/aad/callback I haven't seen this in any other examples and I'm not sure if this is calling a Azure Active Directory specific callback through this endpoint or if somehow the app server should be handling this.
I can see through Chrome Dev Tools when this happens it is sending a post request to www.ourwebsite.azuresites.com/.auth/login/aad/callback and I can see the payload contains the code that I need but the webpage redirects immediately after that request. I have tried to setup a controller with our .Net ASP.NET backend to handle paths from /.auth/login/aad/callback by trying to send a string response back but it doesn't appear that that works.
My Major question is does the url www.ourwebsite.azuresites.com/.auth/login/aad/callback call an azure specific callback function that our app can't interact with? Or is it sending a post request to our server that we should be handling.
After we get this code we will be able to follow the rest of the authentication process.
This picture shows the initial callback call after a user logs into the Microsoft Login page and gets redirect to the www.ourwebsite.azuresites.com/.auth/login/aad/callback I can see in the dev tools that this post request contains the code.
I'm thinking that it's probably something we need to handle on the server especially since it's a post request. Regardless, any help would be appreciated!

Email Link Password-Less Signin : 400 API key expired error on web browser

So I have email link signin (password less) working for iOS and Android, but if a user requests the email and then opens it on a web browser, they see this message:
Error encountered
{"error":{"code":400,"message":"API key expired. Please renew the API key.","errors":[{"message":"API key expired. Please renew the API key.","domain":"global","reason":"badRequest"}],"status":"INVALID_ARGUMENT"}}
I need them to click the link using their mobile device in order for the authentication to work, but ideally I could provide a more graceful message here that tells them to open the link on the mobile device. Any ideas?
I've now got this redirecting to my own website. Long story short - for some reason my Firebase hosting site was not configured properly and thus this authentication url was not being handled as it should. Fixable by recreating hosting site or just creating an additional site under hosting and using that for the email action url.
What I did was:
Create an Additional Site on Firebase Hosting. I made it additional so I wouldn't have to worry about messing with the Dynamic Link setup that is currently working on the default site.
Then under Authentication > Templates in the Firebase console, I changed the action url to use the new site but still have the (__/auth/action?...) path after the domain.
Now, when this url is accessed via a desktop browser, the user is redirected to the continue url (specified in the action code settings of the mobile app) and I display what I want on this continue url.
I noticed that in my Google API console, Firebase created a new Browser key and that it is being used whenever this auth link is clicked. Perhaps this was the issue all along. I wonder if I somehow restricted the wrong key. Anyways, if you run into a similar issue, check your API keys and their restrictions and/or just create a new additional site in Firebase hosting and use that.

Why does Firebase auth uses a "middleware" redirect before returning to my app?

I'm trying to add authentication to my web app by using Firebase Auth and I would like to avoid using the Firebase JS SDK because it's too big in my opinion, and also as an exercise for getting to know the underlying protocols better.
I've noticed that the Firebase Auth SDK doesn't directly redirect to the OAuth endpoint and then back. Instead, it redirects to https://my-app.firebaseapp.com/__/auth/handler which then redirects into the OAuth endpoint with itself as a callback, and then back into my requested callback URL.
So basically instead of:
myapp.com
↓
accounts.google.com/o/oauth2/v2/auth
↓
myapp.com
This happens:
myapp.com
↓
myapp.firebaseapp.com/__/auth/handler
↓
accounts.google.com/o/oauth2/v2/auth
↓
myapp.firebaseapp.com/__/auth/handler
↓
www.myapp.com
I couldn't find any documentation about this API anywhere, but I think that maybe it's an internal middleware for CSRF prevention, or maybe just an API that does the heavy lifting of closing the gap between different Federated Identity APIs.
The reason I'm interested in this is that it can save me some time and possibly money if it does one of the above, and I'm pretty sure I might learn something new from it(I at least hope so).
So, what is the https://my-app.firebaseapp.com/__/auth/XXX endpoint used for, and is there any docs on using it?
It is mostly for ease of use and convenience. You just use one whitelisted callback URL for all your OAuth providers (set up just one redirect URL for all your OAuth providers). You don't have to worry about hosting it as Firebase Auth does that for you. Now you can host your application in multiple domains for production, localhost for development, etc. As long as these are whitelisted in your project, you can sign in with any OAuth provider of your choosing. You can add and remove whitelisted domains from one place in your project settings. Note some OAuth providers in the past used to allow only one callback URL. This would have bypassed that limitation.
It will also work for popup flows too as well as the typical OAuth redirect flow. For example, many developers choose to use popup flows for desktop and redirect for mobile devices.
Notice also for the redirect flow, it does not pass the OAuth authorization code, etc back to your webpage via URL query string, instead it does that via iframe postMessage. So the redirect back to the original URL will have the exact same URL, unmodified. So you can start with https://www.example.com/#login and then go back to same URL to complete login.
In addition, it does not require server side code as is typically done with express passport, etc. No boilerplate code too.
The myapp.firebaseapp.com/__/auth/handler is the URL that signs your users in with Firebase Authentication.
The accounts.google.com/o/oauth2/v2/auth URL signs you in with Google OAuth, but not with Firebase.
This flow is the same for all OAuth2 providers that Firebase supports. So if you'd sign in with Facebook, you'd see firebase auth handler -> facebook oauth handler -> firebase auth handler.

Why can't I add firebase dynamic url as allowed redirect_url for google oAuth?

I am working on a react-native based project where google made it frustratingly hard to implement their oAuth without using an SDK.
First of all, WebView is not allowed to oAuth. So I attempted to implement it through normal browser / chrome tab where redirect is my app id like com.myCompany.myApp but when I add this as allowed oAuth redirect url I get error in google cloud console that this is not a valid redirect id for web based project.
I then tried to set it up with firebase dynamic links, But when I save changes it errors with Request contains an invalid argument.
Different type of OAuth keys have different redirect requirements and best practices. It's too numerous to name them all, so please see this documentation.
In general, if it's an installed app or a mobile app, the redirect URI isn't as important because you are just redirecting back to the app. However for web based app OAuth keys, you will need to be very careful with the redirect because it carries your access token. You can read more about redirect URIs and see what would qualify as a proper URI.
Basically Google makes sure your URI seems ok for your OAuth key type, otherwise it will reject it.
You cant use it because your app id is not an valid URI
This is the path in your application that users are redirected to after they have authenticated with Google. The path will be appended with the authorization code for access. Must have a protocol. Cannot contain URL fragments or relative paths. Cannot be a public IP address.
You cant redirect to an app id there is no way of knowing where the redirect should go. The following are valid redirect URIs
http://test.example.com/index.php
http://localhost:38898/signin-google

OAuth2 Implemenation with Restsharp.Portable

I'm doing an application for android, iOS and Windows Phone using Xamarin.forms.
I need to implement login with most common social for all platforms and I have found on web Restsharp.Portable.
I'm having trouble to understand how to use the library (it was correctly imported) for OAuth2 request.
Does anyone have any example or guide that could be helpful?
I struggled with restsharp.portable due to the lack of documentation.
Instead I used the redirect URL as a way of getting the code generated after the user gives permission needed to request the access token.
I gave the browser the correct adddress for the login/permission screen and for the Redirect I set to a made up address (http://madeupaddress.com) and on the Navigating event of the browser checked if the url started with my made up address, if so, I cancel navigation, closed the browser and take the token from the URI.Query parameters found in the navigating event parameters (or named differently depending on control/platform). I thenapply for the access token using the code via Microsoft HTTP Client.
This was for Windows Phone 8.1.
Thanks go to Vittorio Bertocci
I ended up using Microsoft Httpclient for the access token.

Resources