I have been working on a web application. I installed it on AWS EC2 instance. Currently it is available to all the people over the web. However I'd like it be available only for authorized users. Could you please help me on how to implement the google sign in for the app so that only user who authenticate with google sign in can access it.
I had referred to the google sign in for websites doc: https://developers.google.com/identity/sign-in/web/ . It however talks only about implementing the authentication code but not about how it should be connected to the web app.
Where should I place the google sign in code? is it inside the web app code
OR
Should I create a seperate web page for sign in code and redirect it the AWS/web app server IP address?
Thanks
Arun
Google's API Clients, which will let you implement Sign in Using Google, are hosted on Github. Visit https://github.com/google?utf8=%E2%9C%93&query=api and find the repo google-api-[your_language]-client. Follow this tutorial to get started.
Related
I'm trying to build a plugin for a WordPress App, that uploads file to the users Google Drive space. I don't want the end user to create the Cloud Console Project. but rather just have him give consent so the plugin can access the needed data from his Google Drive account.
When I create OAuth 2.0 Client IDs in the Google Cloud Console (Web Application), Google asks for Authorized JavaScript origins and Authorized redirect URIs. Since the plugin will be portable and can be installed on different websites I can't define this.
How can this be solved that an OAuth2 Authentication by the user can be done, without knowing the URL where the app is running?
Thanks
You cant. Redirect uri must be configured properly, to point webserver the code authorization is running on.
You will need to instruct your users in how to create their own client.
Also as this is a WordPress application, you would need to share your client id and secret with the users. This is also against googles TOS.
possible workaround.
If you put up an authorization server on your own server. The users of your app could then login though that. A refresh token will be returned to their website running your app and stored locally. Your code could then run using the refresh token to access their data.
However you are then going to be responsible for verifying an app with google drive scopes.
Essentially, I'm wanting to create an Oauth Client as an App so I can get data from Dynamics for multiple customers. Does anyone know if this is possible to do in AppSource or do you know of another way?
I have a service that will be served in a cloud different than Azure so there really isn't anything for me to submit as an App and I really don't want every customer to have to setup their own App that gives my service the privileges/access it needs, but it's looking like I may have to.
It sounds like you'll want to register an app with Azure AD (the OAuth2.0 service/identity provider for work and school accounts), and create a multi-tenant app. Then you can configure this app in the Azure Portal to get permissions to the APIs the app wants tokens to call (in your case Dynamics or the Microsoft Graph).
Once this app is written, you can code up your app using one of the Azure AD Auth Libraries. Here's some sample code for a .NET web API. You can find more code samples on Github and search active directory. Moreover, the Azure Active Directory Developer Landing Page is a great place to look for more resources on doing all of this.
I have various sites (on their own domain) with their own authentication systems. What I'm trying to do is combine all the authentication into Google's authentication so the users will only have to log in with their Google credentials. What I'm thinking of is that they would log in with their Google credentials and be redirected to a dashboard which has image links to the other sites. The user should be able to go to any of the sites and be automatically logged in since they were already authenticated. I saw that there's an authentication for Google Apps but is this the same thing for my websites?
What I'm not sure about is how does this happen cross domain? How do the other domains know that the user is already authenticated?
Also, if the user logs out, they should not be able to access any of the sites anymore.
Anyone have any experience implementing something like this? Any resources are much appreciated. I will be implementing this in Coldfusion so Coldfusion resources are a bonus.
Your talking about using Google to login/signup i.e. Using OAuth 2.0.
You will need to register each of your app domains with Google. The user will need to confirm each application to allow access (in your case for signup/login).
Resource on Google Login with ColdFusion by Raymond Camden
The point is you need to establish a certain protocol to build a trust.
Other options are:
Google oauth javascript cross domain
I have some questions about the use of Liferay and Lyferay web services.
I have read the documentation liferay in particular the chapter 11 and 12 (development/Documentation)about the development (or use) of web services in Liferay ... but this documentation does not seem complete than what you can do (Searching on the web you can find different approaches regarding the use of Liferay).
So, here are my questions / concerns ...
Suppose you develop your portlets in Liferay .. This way I can interact with the 'core' of Liferay and also write the front-end of my webapp that will be on Liferay. For example I can authenticate the user in my webapp using the Liferay API.
If I wanted to have an authentication system to access in my web app through my mobile app?
I'm not crazy .. I also would like to have my own mobile app developed with native code. In this case I would expect to have a REST service to interact with Liferay.
I think that, in this case, I have to expose all of the functionality of my web app (portlet) also as web serivices
For example ... we can reason with regard to the user authentication..
I thought that you can:
1. Use the webservice native Liferay to access from the outside.
2. E'possibile to write my own web service.
In this case, I'll have to write a portlet that is actually a webservice?
When it might be convenient to implement a CAS?
As Liferay works as regards the user session (for authenticated users)?
In this case we will provide somehow username and password.
If successful, I will have a token or session ID?
Here I can read:
To call the AXIS web service using credentials, you would use the
following URL syntax:
http://" + userIdAsString + ":" + password + "#[server.com]:[port]/api/secure/axis/" + serviceName
I did not really understand if this should be done only to authorize the untente during login
I probably I am confused but the official documentation for Liferay is not my friend right now: (
Yes you want to use custom portlet services in your native mobile app...
I have written very simple blog for doing exactly this:
Please follow the below link:
http://integrating-java.blogspot.in/2014/04/liferay-mobile-sdk-custom-services-part_4.html
By this you can use your portlet's custom service in your mobile native application.
And best part is you do not have to go through the authentication process if you use Liferay mobile sdk for this thing direct service call is enough.
I am creating a service that will include a website, a mobile app, and a web service.
Both the website and mobile app will talk to the web service to interact with the database and any other backend items.
I would like users to be able to log in with other services (such as google, facebook, twitter, etc.)
I have two questions in implementing this:
1.) Should I use OpenID or OAuth? I'm not sure which is better for the situation. I have no need to actually access features from a users account, I just want them to be able to log in with accounts they already have,
2.) Where should I implement the authentication? Do I have to implement it both on the website and on the mobile app, or could I have both talk to the web service and do the authentication there?
Thanks
If you are just doing authentication and not syncing any account details, I think OpenID is the way to go. From a security standpoint, I would say to implement your authentication on the website and on the app and not in the webservice. You want to handle credentials the least amount possible and especially avoid sending the credentials via webservice if not using SSL.