we have some authorization issues while access sensitive scopes with private Google user data using tokens from Google Cloud Platform credential service.
Verification
Our applications is a self-developed web-service which provides data-gathering functionality for our accounts. After data collection all data is placed in the aggregated form into our database for future analysis. All accounts which will be used with this application are inner accounts of our advertising agency or delegated to us by our clients. No external user accounts will use our developed app.
In order to pass the verification process we have to provide Youtube link with the demonstration of how our web-service works with user data, however data gathering web-service does not have visual interface.
What will you recommend to with this case? Maybe there is no need to pass full verification in case of using only own accounts?
Related
I am developing web platform which has to have 3 type of users (user, admin, partner companies). For the authentication I am considering to use google Identity platform with multitenancy (probably users in one tenant and admins are in different tenant).
As I understand from documentation, how do we integrate identity platform to our application is to create identity platform provider from console and integrate it into frontend with UI. From front-end, without contacting backend service we can sign up, login and logout by calling firebase SDK and it will give us authentication token. From backend I can check that token with middleware and decide if I agree the user as authenticated or not. Correct me if I am wrong.
Then I can get some metadata of authenticated user from the token, maybe email or name etc. But I want to store user related information on noSQL database as well. For example, if user wants to change his email I need to handle it in backend server, also, I'd like to store users log (access and audit log on somewhere else). In case of, I am using frontend UI and SDK how do log the access and audit information on my backend? also, when changing user's information, do I just write handler function in backend end update user's data with REST API or Admin SDK? what is the best practice over here? Or should I better write my own login and logout function on my backend then call REST API or Admin SDK? is there preferred way? Google is showing me only integration way of authentication from frontend?
BTW, I am deploying backend application on google cloud run, and frontend would be developed in react and should be deployed maybe in firebase or in cloud run as well.
Thanks
As per the Documentation,Yes your understanding is correct to integrate identity platform to the application.
You can store the user related information on a noSQL database like Firestore or Firebase Realtime Database. You can write the Rest API to change or update the user's information in the database.
If you want to write your own login and logout function, I don’t think it is necessary because Firebase Admin SDK provides these features. But if you want to manage user authentication in the backend for specific requirements, you can write your own login and logout function on the backend and use the Firebase Admin SDK.
For access and audit log information you can use Firebase Analytics, Firebase Analytics helps you understand what your users are doing in your app. It has all of the metrics that you’d expect in an app analytics tool combined with user properties like device type, app version, and OS version to give you insight into how users interact with your app.
But finally, the best way would depend on your requirements and use case.
I have a "Starter Portal" Power App Portal. I would like to utilize JavaScript and the Web API for querying data. Documentation states
You can use the Web API to perform create, update, and delete operations across all Microsoft Dataverse tables from your portal pages.
Further documentation only lists the CREATE, UPDATE, DELETE operations, and this API being accessible as
[Portal URI]/_api
And I have found how to successfully authenticate using a helper method to get a token for the header:
shell.getTokenDeferred().done(function (token) { ...}
This allows authentication as the user logged into the portal so I believe all relevant Table Permissions, etc. are applied.
But, I would like to retrieve data (HTTP GET). I know this is possible from the Dataverse Web API.. This api is exposed as
[Organization URI]/api/data/v9.1/
Are these really the same API, just exposed a different way for the portal? Is it possible to use the GET endpoints or the second API altogether, authenticated as a Portal Contact user like the previous operations?
It's the same API but permissions are different, you will need to enable the tables you want to access inside the _api endpoint.
You can read more info at this page: https://learn.microsoft.com/en-us/powerapps/maker/portals/read-operations, there is also an XrmToolBox tool to assist you in this operation (but I didn't try it) https://www.xrmtoolbox.com/plugins/PowerPortalWebAPIHelper/
Regarding the Web API calls, I released a new tool to create them (similar to CRM REST Builder) I also added a "Portals" syntax (is in preview) but the generated urls are the same. Link: https://github.com/GuidoPreite/DRB
I have a web app in which I need to use the google translation and language detection API. Following the docs I can consume the API using my service account. However, I have different clients (users) who use my service and each one should be billed separately, so I need a way to calculate the pricing for each user separately.
I read on other SO questions that making a service account per client is a bad idea. Also, I need a way to allow each user to enable/disable the translation feature programatically (my web app is a service on the cloud, so for example if the solution was to create a service acc/user, then I need a programmatic way to do that). Any ideas about the best available way to handle this?
In my application i am using AWS SDK for development. i am able to do all the operations except user registration(In Developer authentication). In AWS they mentioned that for user registration we have to write our own backend code. But i do not have any idea about backend. I am thinking that if amazon provides straight forward solution for user registration it would be helpful. And i gone through server side setup(amazon provided sample code), but there we can register the user through browser not through ios client.
In my application user registration contains emaild, username, password and photo selection options.
For user registartion (developer authentication), i have done more research, but i did not find any direct solution.
Can any one please provide direct solution or any good tutorial to implement our own backend for user registration.
Thanks in advance.
You have a couple options to use Amazon Cognito and providing a complete registration system for users without building a backend: OpenID Connect and Open Source.
OpenID Connect: Since Cognito Supports OpenID Connect-compliant identity providers, you can leverage products out there that federate/broker multiple social providers and expose the federated user via OpenID Connect which have special support for Cognito including Ping Federate, Auth0, and SecureAuth to name a few. I also understood that Okta provides an OpenID Connect identity provider so it might be worth looking into.
Open Source: LambdaAuth is a bare bones project that leverages Lambda and Cognito to provide a registration and authentication backend. Cognito Helper is another one that appears to have more features and be more developed. If one of those have the features you need, they should be easy to deploy and run on server-less Lambda, so they're easy to maintain and you pay only for what you use.
While the details of your registration process will depend on the needs of your application, you may want to consider using API Gateway to front the registration logic you write.
API Gateway will generate an SDK for you which you can use in your application to call your API.
You can have your application call your registration API which handles all of the logic for doing the backend portion of acquiring credentials: http://docs.aws.amazon.com/cognito/devguide/identity/concepts/authentication-flow/#developer-authenticated-identities-authflow
We're in the early stages of designing a RESTful/resource-oriented web service API for a computational lingustics application. Because many of the resources we plan to serve are rights-encumbered, a key design decision has been to specify the platform so that each resource provider can expose their own web service that complies with the API spec. This way, the rights owner maintains control over their content (and thus the ability to throttle or deny access at will) and a direct relationship with the consumer, while still being able to participate in in the collaborative network.
At the same time, to simplify the job of writing a client for this service, we want to allow a client access to the distributed service through one end-point, with the server handling content negotiation and retrieval from the appropriate providers.
Right now, we're at an impasse on authentication/authorization schemes. One of our number has argued for the (technical) simplicity of a central authentication registry, but others are concerned about the organizational complexity of such a scheme.
It seems to me, based on an albeit limited understanding of the technologies, that a combination of OpenID and OAuth would do the trick, with a client authenticating with the end-point via OpenID, and the server taking action on the user's behalf with the various content providers using OAuth.
I've only ever seen implementations (e.g. stackoverflow, twitter, etc.) where a human was present to intervene, and I still need to do more research on these technologies.
Would a scheme like this work for an automated web service, or would it make the client too difficult to implement and operate?
OpenID does assume the user is present to drive a web browser to interact with their OpenID provider and do that initial authentication. But you could have the user authenticate to the end-point with OpenID, and there get an OAuth authorization for their client's automated use.
You should be able to do this without making the client too difficult to implement, particularly if the client is on a platform that allows it to spawn a web browser to drive that initial OpenID bit.