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)
Related
I have a web application which runs until now with cloud run, but without access restriction. Now it should be available only for certain users.
I read https://cloud.google.com/run/docs/authenticating/end-users and also tried both
mentioned ways: Google-Sign-In and the "Identity Platform" tutorial.
If I understand correctly, you have to program the actual user handling yourself in both variants. For example, determining which email addresses have access to the application, etc.
I was looking for a declarative way where, ideally, I only maintain a list of permitted email addresses and the "cloud run application" is only "magically" linked to this. With the result that only these users get access to the web application. That doesn't seem possible?
Ideally, the actual application should not be changed at all and an upstream layer would take care of the authentication and authorization, possibly in conjunction with the "Identiy Platform".
Best regards and any hint is welcome
Thomas
Let me add some sugar to this to better understand all these.
A Cloud Run application is packaged by you, you maintain the source code, if this is a website, placing a login button and handling authentication is your job to accomplish.
A Cloud Run system which is running all this on a hardware, it doesn't "look into" or handles your application code outside of the "code". Simply put it doesn't know if it's a Java or Python code and how to handle authentication out of the box for you - but read further.
If you require a simple way to authorize look into API Gateway it can be placed "before" Cloud Run. It might not be exactly your use case. These exists only for "API" designed services.
That upstream layer you need is the managed Identity platform, but the CODE should be assembled by you and deployed inside your Cloud Run service. The code will be the UI driven part, the authorization logic is handled by the Identity Platform so it reduces the amount of development time.
Your users would sign up using a dedicated registration page, and sign in by entering their emails and passwords. Identity Platform offers a pre-built authentication UI you can use for these pages, or you can build your own. You might also want to support additional sign-in methods, such as social providers (like Facebook or Google), phone numbers, OIDC, or SAML.
Look into some of the advanced examples to get a feeling how authorization can be customized further: Only allowing registration from a specific domain you could reuse one of these samples to maintain that shortlist of users that you mentioned.
In addition to #Pentium10's answer, you can also make all users authenticate to your app somewhat forcibly. (Imagine you're building an internal portal for your company, or an /admin panel for your app that only certain users/groups can access.)
This sort of use case can be achieved by placing Cloud Identity-Aware Proxy (IAP) in front of your Cloud Run service. That way, all requests go through this proxy that validates the caller. This is not like Identity Platform in the sense that visitors don't create accounts on your website (they use existing Google accounts or other IdPs like ActiveDirectory, or whatever you configure on IAP).
I have a little tutorial at https://github.com/ahmetb/cloud-run-iap-terraform-demo/ since IAP+Cloud Run integration is still not GA and therefore not fully documented.
Suppose I have a simple node backend application which when ran needs to connect to a specific GSuite instance, query some things (users, groups, etc.) and then close and not run again until needed, which can mean either a very long time or a few seconds. From what I gathered from Google's documentation there may be multiple ways of doing this, including having an OAuth client and follow the whole flow in setting it up, managing token lifecycle, etc.
However I do NOT want to go with this option for now for various reasons and I am wondering if there is any way of getting access by means of an API Key / secret, like many other 3rd party services allow nowadays. Simply put I would like to generate a key pair somewhere on GSuite, no idea where, and use those keys for auth instead of OAuth, something Google suggests is possible, both on the GSuite Admin app (with a broken link that leads nowhere - not surprising) and on GCloud API and Credentials subpage where you setup credentials (however there it says that API Keys can only be used for very limited resources, none of them having anything to do with GSuite).
I think your best option is to see if what you want to do can be done by a service account. You can create a service account, grant administrator privileges to it in GSuite, enable some APIs, and then that account can do a lot of things without using OAuth directly. The credentials for the service account can then be provided to your application as a json key file, which it can use to authenticate to GSuite. You can also grant service accounts permissions to specific objects like files in Drive, but it doesn't sound like that would be sufficient to your needs.
A guide that may be helpful in the details of how to do this is https://m.fin.com/2017/10/04/navigating-the-google-suite-directory-api/
I want to collaborate with a few people on an application that were creating which relies on the spotify API. I registered the application with my spotify account. Does this mean that all the collaborators can use my client secret and ID? Or do each of them need to individually register the application with their spotify account and use their client id and secret when working on the application?
First: I am not a lawyer.
You should take a look into the Spotify Developer Terms of Service you agreed while creating your developer account: https://developer.spotify.com/terms/
There is this section VI (Access to Spotify Platform):
Security Codes
a. As described on our developer site, to access and use certain
tools provided by our Spotify Platform, you must link your Spotify
account to a developer account. You will be issued one or more unique
I.D.s, keys, passwords, security codes, or tokens (each a “Security
Code”) for accessing the Spotify Platform and managing your account.
You agree to provide Spotify with accurate, complete and updated
registration information.
b. You may only access your account with the Security Codes
provided by Spotify and the appropriate Security Code must be embedded
in your SDA, including in all updates and revisions, in a secure
manner not accessible by third parties. If you are developing a
Streaming SDA, each call to the Spotify Platform must incorporate a
valid Security Code.
c. You may not sell, transfer, sublicense or otherwise disclose
your account or Security Codes to any other party or use it for any
other purpose except in connection with your SDA.
d. You are entirely responsible for maintaining the confidentiality
of your account and Security Codes. You agree to notify Spotify
immediately if you believe that your account or Security Codes have
been compromised and cooperate with Spotify in the investigation of
any compromised Security Codes. You are fully responsible for all
activities that occur using your account and Security Codes,
regardless of whether such activities are undertaken by you or a third
party.
Definition of SDA:
Spotify Developer Application or SDA. “Spotify Developer Application”
or “SDA” means any application, website or service that accesses the
Spotify Service or Spotify Content through, or which incorporates, the
Spotify Platform. Please note that Widgets are not included in the
definition of an SDA.
I assume your collaborators are not classified as "third party". But let them register their own Spotify Developer Application for testing purposes, if you do not trust them since you are entirely responsible for what they could do with those keys.
A little baffled by the Adobe Analytics Oauth integration. I have done many OAuth implementations with other providers in the past, and used the older versions of the Adobe Analytics API.
My company provides services to clients who use Adobe Analytics, we do not have an account of our own. In the past we just needed to be provided the user and shared secret and we were good to go. Now it seems that we need to have an integration created by an admin in the client company, and have them send us the client_id and client_secret securely. This does not grant us access instead it is the first step in requesting access. Once we have this information we can do an OAuth request, using a valid adobe id with proper access and then we will receive the token we need to request data.
With other OAuth integrations I have seen, the client_id and client_secret are not tied specifically to a given account, but rather to the application. In this case it seems we will need to have a new set of client_id and client_secret created for one application, for each account we need access to.
To clarify the use case.
I work for Define Media Group an Audience Development Consulting Firm
specializing in SEO.
Many of our clients are news organizations, for our purposes here,
lets say our client is the fictitious Newscor. Newscor uses Adobe
Analytics and has come to us to provide insight into how they can
improve their SEO performance.
As part of our analysis of Newscor we will need to look at the
Analytics data for all of the requests to their site from Googlebot.
We will use the Adobe Analytics Reporting API to retrieve this data
and perform our analysis.
In the case of a second fictitious company, Newscom, who instead used
Google Analytics, I built an application, I logged in with a Define
Media Group account to the Google API Console and generated a service
account for my application. This provided the client id and secret
needed for completing the OAuth process. Now I just need to have our
SEO contact at Newscom, access our page and complete the OAuth process
with his credentials and I will be able to complete the analysis on
his behalf. Very straight forward.
In the case of Newscor, I am stuck. I have asked my SEO contact at
Newscor to have a service account created and provide the client id
and secret. Instead he provided me his username and password. I told
him that was not what I needed and would not work, confused he has a
user account created for me, and again I have to inform him that this
will be useful, but is not what I need. I send over a link to the
Adobe documentation on how to create an integration account, before
following those directions I am sent a few other random strings of
characters in hopes that one of them will give me the data I need.
Finally, the integration account is created and the client id and
secret are pasted into an email and sent to me over SMTP, plain text
you know. Because users understand security and the complex side of
OAuth, so it is totally reasonable to have them sending client
secrets.
Yes the old credentials were also broken, I thought perhaps, a new API
based on a community standard would resolve that, instead it seems to
have made it worse. Instead of sending me one set of credentials he
has to send me two sets, the client id and secret and a username and
password for an adobeid. The idea behind OAuth as I understand it was
to entirely eliminate this and require that they send me no secrets,
but rather visit a secure page and grant me authorization through the
OAuth process, a familiar login and a few clicks, with secure exchange
of information. The OAuth client_id were between me and Adobe where I
was able to download that information through Adobe's secure website.
That same client_id and secret will be used when Newscom converts to
Adobe Analytics, or another client comes to us with an Adobe Analytics
account.
Avoiding third parties needing to exchange secrets is a primary reason that Oauth exists. Requiring exactly that exchange makes this less secure than a username and password alone.
Posting here, because that is where Adobe directs people to ask questions.
Is this really the way that the new Adobe API works for OAuth or is there something I am missing?
Does it seem reasonable to expect each client to generate a new application integration?
Does it seem reasonable to expect each client to generate a new
application integration?
Well this is just opinion, but yes, I do think it is reasonable to expect each client (Company) to generate their own application Integration.
FYI, the previous user/shared secret you are used to is also tied to an individual adobe analytics account, and is also something the client would have had to setup and provide.
In this case it seems we will need to have a new set of client_id and
client_secret created for one application, for each account we need
access to.
I'm not sure I understand what you mean by this. What exactly are you looking to do with your app? For example, if you are using the Adobe Analytics Reports API, you have the Integration credentials + Your own credentials and you can make Report requests with just that. You do not need credentials for any other user account.
Or, if you have a web interface, you have the option to have the users authenticate with their own credentials.
Overall, the Integration is the middle-man between the Adobe APIs and the user(s) requesting them. The users use their own credentials that they should already have.
Here is an example of it in action (press the login button at the top of the page): https://adobedocs.github.io/analytics-2.0-apis/
Under the hood, there is only one Integration setup, and any individual authenticates with their own Adobe ID login credentials, and what they can actually do within the app depends on what kind of permissions their Adobe ID has for that company.
Perhaps it would be easier to explain the flow if you provide example of what your app actually does?
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.