Keeweb deployed as self hosted on kubernetes and integrated with gdrive but getting "Google hasn’t verified this app" error.
Nothing in log, follow steps - https://github.com/keeweb/keeweb#self-hosting
means exactly that. An app was created on Google cloud console. This app is being used to request consent of a user to access their data. So a consent screen has been configured.
Any app which requests data of a user, and uses sensitive scopes will need to go though the verification process with google in order to be sure that the app is secure.
Unverified apps
An unverified app is an app or Apps Script that requests a sensitive or restricted OAuth scope, but hasn't gone through the Google verification process. Users of unverified apps or your test builds might get warnings based on the OAuth scopes you're using. This is to protect users and their data from deceptive apps.
Related
Hello Stack Community.
I'm looking for formal name of technology/technique that's being used in Microsoft Azure CLI and in Epic Games Desktop application, that is responsible for delegation of authentication from target application to browser, where you perform OpenID Connect authentication and brings you back to target application: CLI App or Desktop App, where you can proceed as logged in user by using authentication you gained via browser.
The steps would be:
you launch target app (CLI, desktop app)
login attempt lets you choose oAuth OIDC via Google or so
selecting it opens default browser, where you proceed with login
You gain auth inside app you started from (CLI, dektop app)
In classic OIDC process you gaining your token in same app/browser environment, while here authorization is expected in app A, token is gained in web browser and afterwards there is possibility to re-use it in completely different application.
I'm wondering is this some particular OIDC extension, usage of some particular grant flow or just some particular hacky way of sharing token across entities?
I found one online resource here but my investigation don't confirm starting of any redirection URL localhost server for toke possession.
I'd appreciate any help in my investigation.
I linked Google Drive from my ERP program.
Yet, from last February 20th, I can't sign in from the program.
I checked my domains from Search Console.
However, I still don't get a consent from OAuth Screen.
What should I do?
The below is the image from OAuth Consent Screen.
Unverified apps
An unverified app is a web application or Apps Script that requests a sensitive OAuth scope, but hasn't gone through the Google verification process. Users of unverified apps or your test builds might get warnings based on the OAuth scopes you're using. This is to protect users and their data from deceptive applications.
If you read the page you will see that your application has not completed the verification process as you have requested one or more of the sensitive scopes.
You have also not verified the domain
Only the developer who created the project will probably be able to login and with a limited quota. You need to wait until the application is verified before it will begin work in a production mode.
I'm building a windows service that would upload files to Box.com under some conditions.
How can I authenticate without having the user go to a webpage and enter the username and password ?
I can't seem to find the details in the documentation.
thanks.
At the moment, you have two options.
You can sign up for the 'instant mode' beta that gets you an authentication token via the /tokens V2 API endpoint, but limits you to accessing a single folder in the user's account.
You can use the V1 authentication APIs. If your app is a company internal app, then we have a V1 authentication API that we can enable for you to do direct logins. However, direct logins are less secure, and generally discouraged.
My app is architected as follows: I have a web service (running on GAE, not very relevant to this question) and the data that this service contains is made available through a website and through mobile and desktop apps.
Currently, the user authenticates to the website via Google ClientLogin and the apps authenticate/get authorized via GAE's built-in oauth provider. (OAuth is being used here mostly for authentication, my app doesn't actually use any external data via OAuth other than the user's unique ID and email address.)
What I'd like to do is expand the number of services that users can use to login. Because of the complicating factor of the apps, it seems I need OAuth. But I can't really properly conceptualize how this flow should go.
Lets take Facebook as an example. When a mobile app goes through the Facebook oauth flow and acquires an access token, this isn't enough - because its my service, not the app, that actually needs to talk to facebook to retrieve contact info and a unique user ID. This leads me to think that the OAuth process needs to happen in the context of my service, and not the mobile app. My service then becomes the consumer and Facebook the oauth providor, and the service holds on to the oauth access token, this happens when a user sets up their account for the first time.
If this is the correct approach, where does that leave authentication for the apps? What happens when the user already has an account and installs a fresh instance of a mobile app? I imagine also going through the oauth process, matching up credentials with the data already stored by my service, and then issuing my own "access token" to the app from the service, to authorize that instance of the app. This seems convoluted and hackish.
I'm sure I can't be the only person who is in effect "borrowing" the account system of a third party for a mobile app with a backend, but I really don't see what the proper way to do this is.
What am I not seeing and/or getting conceptually wrong?
A few colleagues and I once did a project quite similar in nature, back in university. We authenticated our users through either Facebook or Foursquare, using their respective OAuth APIs.
The native Android version of the app opened up a WebView with the OAuth provider's start page, which redirected back to our service after authentication. Then our service did a request for the OAuth token from the OAuth provider (Foursquare has some pretty simple instructions). When we got that token, we set up a session using cookies, which we could access from the app.
To validate sessions, we just checked whether the access token was still valid with the provider. We also used the respective providers' unique user IDs to distinguish users.
So yes, what worked for us is: Make the app authenticate & authorise your service, not the app itself.
We've got a working salesforce api implementation that gets and sets properly with a production salesforce account. We've recently come across a user that rather than using their production Salesforce to connect to our implementation, has set up a sandbox for a limited trial.
I personally have a sandbox that I can properly connect to. It is not, however, connected to a production salesforce instance.
I'm wondering if the fact that they have a production salesforce instance that they created the sandbox from will affect the API login to the sandbox.
I'm currently receiving a "your salesforce login is incorrect" even though I am absolutely certain the credentials and security token are correct.
If you need any other information, I'll happily include it.
Thoughts?
Login requests for sandbox accounts should goto test.salesforce.com not login.salesforce.com. You should also login through the webapp and look in login history (in setup) that'll sometimes have more information.