Context:
I am currently working on an embeddable widget, something akin to Intercom or
Hotjar, and have the need to authenticate users. Thus far, I got away with
using Passwordless authentication using Firebase auth but users complain that
it's a high friction process, and they'd rather not do it at all. The ideal
authentication solution would be to let users use their Google or Facebook
account and authenticate via OAuth2.
Problem:
Firebase Auth restricts authenticating via 3rd party auth providers if the
domain the user authenticates via is not whitelisted in the authorized domains
list. So if the user puts the code in abc.com, and tries to auth via Google
firebase rejects it because abc.com is not in the whitelist. Whitelisting the
domain of every client is unorthodox. I feel like the way I'm approaching it
is wrong because I can't correctly build up a mental model of how this would
work out. Technically cookies, sessions, etc. are pointless.
Question:
How would I go about providing the ability to let users authenticate via 3rd
party auth providers? Is this even technically possible?
Potential Solutions:
Host the widget at the main app in a dynamic route (the website where the user
would get the widget's code) and render this route as an iframe in the
client's website. (ex: /widgets/{widgetID} would have the widget). I don't
want to do this really because iframes are a serious pain but this sounds like
the most feasible.
I'd like to know more/better solutions to address this particular situation.
It doesn't matter even if it's from a different cloud provider or a different
authentication service. The goal is to authenticate the user from the widget
ideally via a 3rd party auth provider like Google.
EDIT: This is the error that I currently receive:
widget.js:2 auth/unauthorized-domain This domain (xyz.com) is not authorized to run this operation. Add it to the OAuth redirect domains list in the Firebase console -> Auth section -> Sign in method tab.
Based on your use case, you need to verify the domain ownership xyz.com by following this guide
After that you need to add xyz.comto Authorized domains your, as the error message mentioned.
Add it to the OAuth redirect domains list in the Firebase console -> Auth section -> Sign in method tab.
For more information please check this guide
Is not possible enable Google Sign In by using a domain unverified or unauthorized, this is to protect the access to your sites/projects by restricting the usage of the Firebase/Google credentials only for configured domains.
There is no way to disable this setting, Google sign in uses Oauth2 as authentication framework
Related
I'm developing a 'CMS' for use in clients websites and I would like to include a few analytics views. I have searched and I found some things like this one in google analytics demos and tools (https://ga-dev-tools.appspot.com/embed-api/third-party-visualizations/), but it needs you to be logged with the analytics google account to show them.
I have seen Worpdress plugins that shows analytics in the dashboard and you only have to authorize them once and not to be logged in google. ¿How is this done?
I need to show client analytics in the dashboard of the CMS, but I don't want to ask for login everytime or request to be logged in their google accounts.
Thanks to anyone who can help.
The Google Analytics embedded API is built using JavaScript. JavaScript is client sided and there for an implicit login. Implicit logins do not contain a refresh token so when ever the access token expires normally after an hour you will need to login again.
Your Word press plugin assuming its the one i think it is. Uses php and is there for server sided and uses a hybrid login which probably requested offline access from you when you authenticated it first time. Offline access gives you a refresh token which can then be used to request a new access token when ever the plugin needs to access Google Analytics.
Assuming that your client only wants to see their own data they should be using a service account. Service accounts are preauthorized and will there for not require that you authenticate them again. Service accounts only work with server sided languages like php you can not use service account authentication with JavaScript.
I need to authenticate users in browser (not mobile app) using AWS Cognito with username/pass, not FB/google IdProviders.
There are a lot of docs but they seem to be separate blocks which either incomplete, do not fit the requirements or do not fit each others :(
I created Cognito User Pool, then Identity pool and tied the userPool to the idPool, then I stuck. Do not know which library to use and how to use it.
The closest I find are:
https://aws.amazon.com/sdk-for-browser/ but my experience is not enough to convert their FB samples to not-using FB
https://github.com/aws/aws-amplify but using this lib I'll have to study React/Angular from the very beginning (I'm not a front-end developer, sorry) and I have no clue how to convert their npm-based samples to front-end javascript (npm is for NodeJS thus back-end, isn't it?).
All I need is plain html form with username/pass, send the request to Cognito and a way to check during the next page load whether the password was correct. If it matters I will use AWS Lambda as back-end for processing future tasks.
How can I do it? Is there a tutorial/doc for my case?
Thank you.
You can use AWS Cognito UserPools Hosted UI for your use case. The simplest form of authentication is using the Implicit Grant.
For more information about setting up Hosted UI refer Add an App to Enable the Hosted Web UI.. This will create a UserPool where users can register them self (If you plan to restrict this, you will need to either add users using the AWS Web Console, Cognito UserPools or using their SDK)
The steps are as follows.
Set up Cognito Hosted UI and register your application domain. This will create the login/registration pages for you where each of this will have a unique URL. What you have to do is, if the user is not authenticated (Let's discuss how to detect it later), you need to redirect the user to the Login page.
In the Login URL, you also need to specify the redirect back URL to the application so that after a successful login, Cognito will redirect back the user to the application providing the token in a query string.
You can then access the id_token from inside the application and use it for querying the backend.
Since the id_token is a JWT token you can verify it at your Backend using the public key available at the Cognito token endpoint.
To implement the JWT verification, you can also refer Cognito JWT Token validator NodeJS module.
Note: If you need to keep the user's logged in for a longer time period (Than 1 hr), you might need to use the Code Grant flow which will return a Refresh Token, which could be used to retrieve new id_tokens programmatically.
Background I have some experience implementing Oauth1a and Oauth2 as a client to connect to 'trusted' 3rd party services (twitter, facebook etc), but first time implementing the resource/authorization servers.
I have a basic but not strong understanding of different grant types, and how Oauth attempts to solve the authorization of a user/resource, while protecting user information (login information etc).
Scenario: we are creating a client-side application (reactJS) which must submit some basic information to a WordPress site. We control (are the authors of and will host) both react and WordPress on the same server.
We are using WP Rest API:
http://v2.wp-api.org/
And Oauth server plugin for wordpress
https://en-ca.wordpress.org/plugins/oauth2-provider/
Question
The further we get into implementation, the more I ask, what security to I gain at all by adding Oauth in this scenario?
For development and testing, the permissions callback on the POST to our REST endpoint is TRUE (open to any request), and now we are trying to secure it so only our application can submit information to WordPress.
The author of the Oauth server for WordpPress describes for this:
The access token used to preform a CRUD WP REST API action MUST has been acquired via the password grant type (user credentials).
Which requires embedding the following in the client:
client ID
client secret
wordpress user ID
wordpress user password
since:
The access token MUST be assigned to a user id with the correct
WordPress capabilities to preform the CRUD action.
Just to get back an access token.
Note: users do not log in via our react application. The application itself acts as one user in this case.
I must be missing something, exposing the WordPress user name and password seems less secure than skipping Oauth completely, leaving the POST endpoint open, and implementing some kind of submission abuse check, via submission rate, IP or other.
With Oauth2: Someone in control of the client can watch the XHR request and retrieve all information necessary to submit malicious data.
Without Oauth2: someone could use one of many discovery techniques to find our public endpoint and try to submit malicious data.
Things which I may be missing: should I be encrypting/hashing the password, secret, ID etc before embedding in the client?
Should I be separating out our authorization server from the resource server?
Have I missed the point, and Oauth is not a good candidate for this scenario?
Any insight or clarification greatly appreciated.
I have an ASP.NET MVC website deployed as Azure website (called website). That website has a section that needs authorization. I already have set up Windows Azure Active Directory (WAAD) to protect access to that section. Once that protected section has loaded, it will load a Javascript app that allows integration with the Azure Mobile Service.
I also have a separate Azure Mobile Service that I use for data storage (called mobserv). I want to access mobserv table and api endpoints from website. I am using the .NET backend for Azure Mobile Services.
Of course, I need to protect those mobserv endpoints using [AuthorizeLevel].
Tutorials show how to do this when I want to authenticate as Application (using [AuthorizeLevel(AuthorizationLevel.Application)]) - just add a reference to the proper Javascript Client (MobileServices.web-1.2.5.js), provide mobserv app id and token. CORS is set up to allow interaction. So far, so good.
But now, I want to protect certain endpoints using [AuthorizeLevel(AuthorizationLevel.User)]. So now, the request has to be authorized as User. Since the website already has been protected by WAAD, I do not want the client to perform a new sign in for the javascript client - I want to reuse the current WAAD authentication headers to have a Single Sign On Experience, so that mobserv will recognize the user.
I have not found any hints on how to do this. Tutorials only show application level auth against mobserv or using explicit login dialogs.
Does anybody have a clue how to do this?
Following up on vibronet's post, Mobile Services does support HTTP POST of an access token, but the access token must specify the audience as your mobile service. So a token issued for your website will not work on its own. You will need to transform it through one of the AAD flows.
So in AAD, you need you have two web application registrations, one for your web site and one for the mobile service. On the mobile service registration, you would need to define permissions that can be exposed to the other resource. The first section of the Mobile Services + ADAL tutorial ("Register your mobile service with the Azure Active Directory") walks you through this. Then, instead of registering a native client app which accesses that permission, you would go to your web site registration and configure the access there.
Once you have an AAD token for your website, you can leverage this permission to get a token for the mobile service. This can best be accomplished using an on-behalf-of flow in the Active Directory Authentication Library (JS or .NET, depending on where you want to do things). The AAD team has a nice sample on how to do this, and mobile services also has a tutorial which might be helpful, although it does mobile service access to SharePoint Online as opposed to web site access to a mobile service)
Then you can send the token to your mobile service using the "client flow" method, as described in "How to: Authenticate Users" for the HTML/JS SDK. For AAD, the call will look something like:
client.login(
"aad",
{"access_token": "<TOKEN-FROM-AAD>"})
.done(function(results){
alert("You are now logged in as: " + results.userId);
},
function(error){
alert("Error: " + err);
});
The user will not see any new UI, but they will be logged in, and subsequent calls from the SDK will be authenticated.
It might also be easier to do this from your MVC backend. I believe you can get the access token from the ClaimsIdentity, and then you can just use the Mobile Services .NET client SDK to do the login action and facilitate calls from the MVC site to your mobile service:
JObject payload = new JObject();
payload["access_token"] = "<TOKEN-FROM-AAD>";
MobileServiceUser user = await App.MobileService.LoginAsync(MobileServiceAuthenticationProvider.WindowsAzureActiveDirectory, payload);
token reuse 'as is' cannot be achieved given that the tokens you get for website are scoped to your app and should be rejected if forwarded to any other resource. From the AAD perspective there are various flows that would allow you to trade in your original token for a new token meant to be used with a web API - all without requiring any new action from the user. However your scenario includes some Mobile Services specific moving parts, hence I am not sure how that would apply here. I am flagging this post for the Mobile Services guys, hopefully they'll be able to chime in.
I am trying to create a web app using meteor. I am hoping to use the app on my college campus and I wanted to use the college's authentication service so students could login with their college email address and password. I need to query (with HTTP POST request) https://www.bowdoin.edu/apps/mobile/login.php to get a 0 indicating incorrect user info, or anything else to indicate the user can successful log in. I would like to use the meteor accounts-ui styling and login format and simply authenticate using the POST request. I also want to keep the functionality that allows users to have an id associated with their email address so any user content in the app will stay associated with that user when they log in again. I would like this to be implemented in a way that uses as much code from the accounts-base and accounts-password packages meteor has. The only unique login feature in this case is a post request compared to the Oauth typical of other services.
If you want to use Meteor's built in Accounts package, I think your college's authentication service needs to support OAuth. Per http://docs.meteor.com/#meteor_loginwithexternalservice:
Meteor.loginWithExternalService([options], [callback])
These functions initiate the login process with an external service (eg:
Facebook, Google, etc), using OAuth. When called they open a new
pop-up window that loads the provider's login page. Once the user has
logged in with the provider, the pop-up window is closed and the
Meteor client logs in to the Meteor server with the information
provided by the external service.
See that section of the docs and try to build your own accounts-bowdoin package similar to the examples (accounts-github, etc.); see https://github.com/meteor/meteor/tree/d477c8d03bb078f7e8e85dbe4b51db7ae5689573/packages/github and https://github.com/meteor/meteor/tree/d477c8d03bb078f7e8e85dbe4b51db7ae5689573/packages/accounts-github for example.