Today I received an email with the above as subject and this in the body :
Dear Android developer,
To keep your access to Google APIs, review the OAuth client used by your Android application by September 30, 2019.
Google requires developers to register all Android apps that request Google Account data and interact with Google APIs. The following Android package name you maintain may require the registration of an OAuth client:
com.myappname (not my real app name)
To register an OAuth client, make sure to either:
Have an existing project on Google Cloud Platform for the app you publish.
Create a new project and configure it correctly.
For the app, make sure there’s an Android OAuth client for the package name and SHA-1 signing-certificate fingerprint. If your app uses certain sensitive or restricted scopes, you’ll also need to submit your app for verification.
Apps without a properly registered OAuth client may not get Google Account or API data after September 30, 2019.
Thanks,
Google API team
I have a GCP project that has 2 OAuth 2.0 client IDs with the package name for this Android app (one Debug, one Release) and SHA1 fingerprint. Google login has been working for years with no issue. App is also verified (though we don't use any sensitive scopes). Anybody received a similar email or know what possibly might be missing?
This is neither a misfire or a threat. It's more of a reminder than anything else. All people who interact with Google User data get this email, and the point of this is to simply tell people "Hey, if you need to, register an OAuth client, do it by September 30th.". This is explicitly clear on the wording of the email. You can see here:
The following Android package name you maintain may require the registration of an OAuth client
The keyword being "may". Since, from what you've posted, you already registered your client, you should be good to go. Everything beyond this:
com.myappname (not my real app name)
Is nothing more than instructions on how to register your client. Everything above it is warning, that if you haven't, register your client. It's saying that it's possible that you haven't registered your client, so make sure you have.
Long story short, if you registered your client, you're good to go.
Related
As an ios/android app developer, my pain point is having clients sign up for the various 3rd party accounts needed for their app to work (e.g. google cloud, mapbox, firebase, etc.), however with 2-factor authentication (2fa) being a requirement on most accounts, it makes it difficult to get into these accounts easily as the developer (since 2fa requires a code being sent to the client which must be entered in a limited time period).
Has anyone found an easy solution for working with 3rd party accounts for their clients especially when 2fa is being used?
Well, at least Google Cloud and Firebase in this case have the option to add additional users under a given role. In this case you would likely want the client to be Owner of the project, and ask them to invite you as a developer, this way you can sign in with your own Google account (either gmail or your personal if you use google workspace), hence bypassing the need for 2FA.
In general, there are things that you don't really want access to as developer, such as billing information, so it makes sense to ask for limited access. Both Firebase and GCP have predefined roles for this, you can do some research on them to find out which makes the most sense for you and advice your client.
Read more about the roles here:
GCP: https://cloud.google.com/iam/docs/understanding-roles
Firebase: https://firebase.google.com/docs/projects/iam/roles
Side note:
If you are working as a freelancer, I would recommend to never create accounts for your clients, if you are working with specific service, ask your client to setup the account (this will primarily protect you, if the client backs out or the server costs for development build up if the project is taking long time to finish)
So I have this really old UWP app that has been using the Live/OneDrive SDK to provide authentication and identification for at least 7 years now. The app is registered with Microsoft Account Authentication which provides a Client Id and Client Secret to identify the app when an authentication request is made.
When I use the SDK for authentication (OnlineIdAuthenticationProvider), it returns a unique Id (CurrentAccountSession.UserId) with which I can determine which of my users is using the app and then use that unique Id to persist/retrieve information the user provides.
The problem is....The OneDrive SDK is super old (hasn't been touched in over 3 years), outdated (.NET 4.51...no .NetStandard implementation) and Microsoft is pushing everyone to use MSAL and Graph instead. Fine.
But how can I do that and still be able to tie the person who is logged in to the app to the information I am storing for her/him?
From what I'm seeing, in order to use the new SDKs, I have to register my app, again, in the Azure portal and use a new Application (client) ID. If so, when my user logs in...my expectation is that any identifier that's returned to my app in the authentication process will not be the same as the UserId I've been using for almost a decade.
Has anyone done this? I can't be the only person who has encountered this problem...can I?
Any help would be greatly appreciated....
This question already has answers here:
How do I authorise an app (web or installed) without user intervention?
(2 answers)
Closed 5 years ago.
I have a client id and client secret for my Google Container Engine app obtained via Credentials and I just want to do some local testing of the JSON API endpoints.
How can I convert this into a Bearer token so that I can just get some work done? Is there a Google page where I provide these things and get a token that I can use in my app?
I don't want to have to write an entire OAuth handling mechanism at this point in time (which would use the flow described in oauthplayground). It's an app to be run only for my account, in headless mode, on a trusted machine, to manage my cluster.
NOTE: must not require any proprietary software installations (e.g. the Google SDK).
Google provides an API Client Library for Java, which itself depends on an OAuth client library.
For the project of 9Cards launcher for Android, within the back-end, we had to use this library to fetch applications usage statistics from Google Analytics. In our code, because it is a case of "server to server" authentication, we use a Service Account's credentials. The code issues a request from Google a short-lived OAuth2 Auth Token. The library may provide similar features if you use a Client-ID and Client-Secret.
Regarding the issue of licenses, the library is published under Apache License v2, so in that regard it is not too proprietary.
I have a client id and client secret for my Google Container Engine app obtained via Credentials and I just want to do some local testing of the JSON API endpoints.
Good start. I guess by "the JSON API endpoints" you mean the Google APIS. Make sure you created OAuth Client IDs and not one of the other options.
How can I convert this into a Bearer token so that I can just get some work done? Is there a Google page where I provide these things and get a token that I can use in my app?
Yes the OAuth Playground will do that for you. The detailed steps and sample code to consume the token is at How do I authorise an app (web or installed) without user intervention? (canonical ?)
I don't want to have to write an entire OAuth handling mechanism at this point in time (which would use the flow described in oauthplayground).
Follow the steps linked to above and you will see that you don't need to write any code at all. Once you have the refresh token (a one time procedure), you're all set. I exaggerate slightly, you do need one line of code to post the refresh token to the Google Oauth endpoint to fetch an access token. See the bottom of the linked answer for an example. Or you could just compose a curl to do it from the command line and put the Access Token into an environment variable.
I just wanted to avoid the whole thing and get a code printed on the screen
A bit like https://youtu.be/hfWe1gPCnzc?t=198
I am in need of advice on how best to tackle the following scenario and best practices to implement it.
Our company wants to overhaul its old IT systems and create new website app(s) and possibly mobile apps down the line for its employees and contractors to interact with.
So i was thinking about creating an api that both the website apps and mobile apps could be created from...
https://api.company.com/v1
The advice i need is in relation to security/authorization of the api. My thoughts at present in how to implement this would be that the employees/contractors would interact with the api through the companys website app(s)/mobile apps which would then communicate with the api and set the appropriate access permissions
WebsiteApp.company.com ->>> api.company.com/v1
mobileapp ->>> api.company.com/v1
First thoughts is just setting up a username and password for each user on the api side and let both the websiteapps and mobile apps use this. The problem however is that the contractors and possible some employees cannot be fully trusted and could pass on username and passwords to third parties without the company's permission. So my question is really what other security/authorization/authentication strategies should i be looking at to overcome this situation. In a perfect world each user would have to authorize each device/mobileapp/websiteapp he/she wants to access the api from...
Is OAuth 2.0 capable of this?, not sure if its capable of specific user/device/website scenario though ?
Technologies thinking of using are:-
API
Node.js with (Express js? or Restify?) , MongoDb
Consumer Apps
Website Apps (Angular Js, Backbone etc..)
Mobile Apps (PhoneGap, Jquery Mobile etc..)
Many Thanks
Jonathan
It seems that your main concern is that you can't trust the people you are giving access to, and if this is the case, you probably shouldn't be trying to give them access in the first place. If these apps are to be used for any confidential information or intellectual property that you are worried about someone else seeing if the contractor/employee gives away their password, then you have to consider the contractor/employee just taking the information and giving it away.
In this situation your username/password should suffice for authentication, however you should also consider very tight permissions on who can access what. If you are worried about information getting out, everything should be shown on a need-to-know basis. If a contractor doesn't need a specific piece of information, make sure it isn't provided to his account.
You could also consider tracking the locations (IPs) that an account is being accessed from. Perhaps when an account is accessed from a new location have the employee/contractor complete some task to validate the account; which could be anything from entering a validation code (similar to a two-factor authentication), to calling a help-line and having the location authorized.
This might be a bit late, but as i am going through the same process (What is the correct flow when using oAuth with the Resource Owners Passwords Credentials Grant)
We have not figured out the core implementation what you want to do sounds similar to what we are trying to do for our service.
From my understanding it depends on the apps and if they are trusted or not and what you plan to do with your API moving forwards. If the apps are trusted you could potentially use HTTP-Basic over SSL which is a viable solution.
For us, we are going to create a suite of trusted official apps (Web, Mobile etc) via the API and then open it up, so we are deciding to go through the pain of oAuth2 where for our apps we will use the Resource Owners Passwords Credentials Grant type where you swap a users user name and password for a token which is what the client will use to interact with your API with the trust implicitly defined.
When we open up the API for 3rd party consumption this model wont work and we will go through the processes that all the major sites do and get explicit permission from the user on what the 3rd party apps can do with their data.
So I'm having trouble understanding something...
If you do Oauth for Web Apps, you register your site with a callback URL and get a unique consumer secret key. But once you've obtained an Oauth for Web Apps token, you don't have to generate Oauth calls to the google server from your registered domain. I regularly use my key and token from scripts running via an apache server at localhost on my laptop and Google never says "you're not sending this request from the registered domain." It just sends me the data.
Now, as I understand it, if you do Oauth for Installed Apps, you use "anonymous" instead of a secret key you got from Google.
I've been thinking of just using the OAuth for Web Apps auth method, then passing that token to an installed app that has my secret code embedded in its innards. The worry is that the code could be discovered by bad people. But what's more secure... making them work for the secret code or letting them default to anonymous?
What really goes bad if the "secret" is discovered when the alternative is using "anonymous" as the secret?
The main difference between OAuth for Web Apps and OAuth for Installed Apps (e.g. "anonymous"/"anonymous" as your consumer key/secret), is the approval page.
For installed apps, there is no way for Google to verify the identity of the
application so a yellow warning box is shown to the user saying so.
For web apps, there's an actual URL (of the app) that can be verified.
Hence, no ugly warning box is presented to the user.
The only thing you need to identify yourself when doing an OAuth call is the signature which is a HMAC-SHA1 string signed with your consumer secret. There's no relation with any domain whatsoever.
The only thing you need to keep reasonably safe is the consumer secret. I don't quite get what you mean by "anonymous" though...