I have a web app and API for the app configured and completed, but work is now requesting more apps. The apps are web-heavy with a light API for mobile functionality. A monolithic apps seems out of the question, so I decided to make each one individually. Each app will have their own layout, database, and API. However, the one thing I want to share among all apps is the users' password, api token, and firebase messaging token. A separate app will be created just for authentication with IDnumber, password, api token, and fcm token. 4 simple fields. This single app will be the only one doing any writing to it's DB and this single table.
Creating requests to the auth app to verify every request to each API seems inefficient, so I was wondering if there was a way for the apps to tap into the auth database and verify tokens and passwords directly. There would be no joining of tables cross-apps and no cross-app creation/updating/deletion. Problems with keeping models and schemas synced make sense, but would read-only custom queries eliminate those issues?
Integration at DB level is messy - any change would need to be done on every application using it, and the security is a concerns too.
The typical solution for your problem (having several application share a unique authentication source) is OAuth - a way for the multiple apps to delegate authentication to your "Auth App". This is well supported by frameworks such as Devise.
Related
First of all, sorry for my bad English :)
I am building a Gmail addon which integrates file uploading to an external website using their API. The API have an auth endpoint which uses plain authorization flow i.e. takes email and password of a user to authorize and return authorization token. That token is then used in the subsequent call of file uploading process.
My question is, it has been mentioned in gmail addon guide that an app should use oAuth when connecting to a third-party service. However, the related website's API do not have oAuth but use plain authorization flow. If I create a login form with email and password fields using the card service, would that be okay and approved by google to be listed in the addons directory? Creating oAuth on third party service is not in my hands
Thank you!
Q: would that be okay and approved?
My experience is that it is OK to use basic authentication (since a lot of APIs still use basic auth, it would be devastating if the use of API was prohibited), most likely you will be approved. However, if there ever be a version of the API that supports OAuth, please, migrate as soon as possible.
Caveats
You mentioned creating a login form in CardService - please, be aware that there are no "password"-style TextInputs, so all characters will be visible all the time + there isn't, as of yet, any support for input event, so you won't be able to emulate the behaviour easily.
If you are planning on storing the credentials, try to avoid using PropertiesService - it isn't considered a secure storage (though if credentials are to be entered only once, storing the token should be fine).
You will still be asked to implement the authorizationCheckFunction.
I am building an application that consists of two strongly separated parts:
Backend server is running on AppEngine that access gsuite domain data using Google service account.
Spreadsheet plugin written with Apps Script, that is directly installed by the users.
Spreadsheet plugin should access backend server REST endpoint.
I want to implement authorization for the "Apps Script" -> "Backend Server" connection. The only information I found on this Make requests to services with OAuth
I don't want to implement my own user management and want to use the Google Accounts for authorization. As far as I understand the single way to do this is implement OAuth on the server side and then follow o.
I wonder if there a better approach or best practices to implement this?
Unfortunately, there isn't another mode of "authorisation" besides the one you've already mentioned/explored i.e OAuth.
What I would recommend as an alternate is to use JSON Web Tokens (JWTs).
Twilio's Authy uses it to create user registrations without any PIIs and JWTs in Google Apps Script should help you with that.
Hope this helps.
I am trying to work out an application using
Dotnet Core 1.0
MySQL as the data store
Authetication and Authorization
Entity Framework
Ubuntu 16 machine
I have succeeded in creating a sample API to fetch data from MySQL database using entity framework. Now I want to introduce Authentication using email as username and Password.
I tried several method from different blogs but unable to achieve this.
What I am trying to achieve is Custom Authentication for the api where user will send username and password to login Api. The login Api will return an access token and refresh token. Using this access token, the user can call other APIs.
Later on I want to add Google and Facebook Authentication too.
Is there a way to do this?
Everything you want to achieve is possible. However there are some caveats.
Yes you can do this. You will need to use the resource owner grant which is turned off in identityserver 4 by default. I suspect the reason for this is because passing user credentials into an application is an anti-pattern, it is there to typically support legacy systems, also it does not authenticate users in the explicit sense because the credentials could come from an un-trusted source (as an example). You can read up about the grant's generic value here. You can find samples here.
The safer pattern is to use something like Implicit Flow which is good practice if you cannot guarantee trust between clients and your API.
As for social logins this is possible. There are tonnes of samples online but here are the official docs.
There is a project on github, https://github.com/diogodamiani/IdentityServer4.MongoDB and a corresponding nuget package that will send you in the right direction. It's obviously MongoDb, but the same premise applies.
First I apologize if I'm a dolt and am missing something obvious, but I've spent a few hours scouring documentation and am lost.
I'm trying to write a python script that will upload a bunch of images to a single user's Google Drive. The user already exists and will never change. I am not writing a web app and don't plan to use any user interface whatsoever. Everything will be done through code.
As best I can understand from the Google documentation, I have two choices:
1) Write a web app and register it to use the Drive DSK. This of course requires having urls and such for the web app.
2) Create a service account, which ties my "app" to a new service account email.
Neither of these options works for me. Is there any way to simply log in to a single user account and access their drive through python scripting?
There is a deprecated API called ClientLogin that would enable you to use the username and password for a login to access that Drive data.
But the basic idea is that you should be using something more secure -- from your users' point of view -- that allows them to authorize you without giving you their password.
For your use case it is possible that the user is you or someone you know and that you are accessing their account through a more personal kind of authorization. In that case, ClientLogin may be your best choice. If this is an application designed to be used by arbitrary users, the deprecation of ClientLogin is for a good reason and I would urge you to bite the bullet and choose one of the supported options.
The correct solution is to separate the authorization phase from the access phase. The authorization process needs to be run one time only, and can be done from a simple web site. The result of this is a refresh token which is analogous to a username/password. You will need to be aware of the security implications. Make sure you only grant drive.file scope to minimise the impact of a security breach.
Since you are uploading images, you might also want to look at the picassa api.
I have a general comprehension question about OAuth access token retrieval for a Google Chrome Extension.
I have a popup HTML window in the browser that uses Jquery to request data from the server (a LAMP stack on AWS). The data is presented by PHP scripts which access a MySQL database. All very basic stuff.
I now want to implement a push messaging system using Google Cloud Messaging to alert users of new content that they can check. However I don't really understand where I should request the access token and how to listen for the response. I figure it should be in the PHP scripts but all the Google documentation that I've read states the user has to be present in order to allow access to push messaging. That tells me I should put it in the JavaScript but I feel this is a bad idea because every user could potentially request an access token when I think I only need one every 3000 seconds or so. If my app was completely implemented in PHP I'm sure this would be possible and now I'm worried that splitting it up like this leaves push messaging out of the question. Am I missing a crucial detail or just out of luck?
If the data access you need isn't user-specific, then you're right, there's no good reason to get a separate token for each user. Check out https://developers.google.com/accounts/cookbook/roles/Apps which discusses some options.