Relation between GCP project and OAuth app - google-cloud-platform

Trying to set up an OAuth flow for my web service so that it is able to access GCP services and I am not.
When going to the Credentials Service, there seems to be the option of having only ONE “OAuth Consent Screen”.
However, one can issue multiple OAuth Client IDs.
Does this just imply a mandatory 1-1 mapping with an OAuth App and a GCP Project?

An OAuth App (Client ID and Client Secret) is created in a project and is tied to that project for the purposes of management and control.
However, the identities that authenticate using that OAuth app are not tied to a single project. IAM within each project controls who/what can access resources.
A precise answer requires more details such as who is the OAuth Identity Provider (Google, Google Workspace, Google Identity Platform, etc.) and what resources and services the app grants access to.

Related

Is there any OpenID Connect Identity Provider that can delegate autentication to other OpenID Connect IdPs?

I'm facing the following scenario:
There are several companies each one with its own OpenID Connect Identity Provider (IdP) which federates users from their respetive LDAP servers. These providers are used to perform SSO in the context of each company.
There's a requirement to create an application that offers a common login for all the users of those companies.
The idea is to provision or use an existing cloud solution (AWS Cognito, Google Cloud Identity, etc., ...) that offers a shared login screen but delegates/federates the actual login to each of the company IdPs.
Are there any solutions that allows this?
Could you point at any documentation/guide to implement it?
This is just standard OAuth and OpenID Connect behaviour, with these 3 roles:
Application, uses OIDC to redirect to ...
An Authorization Server, which you own, and which redirects to ...
An Identity Provider
So you need a standards based authorization server and to configure your app as an OAuth Client. Then include the openid scope so that OpenID Connect is used. SAML based identity providers can also be supported in this flow, even though your app only uses OIDC.
The way to manage this with best usability, is for the authorization server to present a usernane authenticator, which captures a user identifier first, such as an email. It then runs some custom logic, such as a user lookup, to determine which IDP to route the user to. The user then authenticates at the IDP.
After authentication, the IDP issues tokens to the authorization server, which validates them, then issues its own tokens to the application. In particular the app gets an access token whose scopes and claims you can control. Your app can then send these to your APIs, which can authorize access to business data correctly.
Aim for behaviour similar to that above, or adjust it based on your preferences. Then trial it, eg with a cloud or Docker based authorization server, and ensure that you select one with sufficient extensibility to meet your requirements.
Note also that Stack Overflow answers should not recommend particular vendors, so I have not done so.
There is a solution called cloudpods using which you can manage both on-prem and public cloud resources. Cloudpods supports integration with multiple cloud providers like aws, GCP, azure, alibaba and etc.,
Is there any OpenID Connect Identity Provider that can delegate autentication to other OpenID Connect IdPs?
Yes. https://github.com/apereo/cas is one. You can set it up as an OIDC identity provider and have it then delegate to as many OIDC Identity providers as you want.

Creating Application for other enterprise to SSO and list directory users?

I am trying to create a web application. This app is a B2B PAS model.
One of the features of the app is, an organization using GSuite, can onboard our system and then all its users can log in to our software using their org's google ids. However, in the application, one user can assign task to another user in org. So our application should be able to list all users of the org too.
How can both these features be achieved?
I have tried the SAML approach, by creating a custom app from Gsuite admin console. However, can SAML be extended to also list users from the organizations which the SAML app belongs to? (Basically trying to use the Google Cloud Directory API)
What other alternative approaches should I look for if pure SAML doesn't work out?
P.S tech stack I'm using is Nest JS for backend and Angular for frontend
If I am understanding properly you are looking for the way to populate all users/ID from organization to your SAML App. Single sign-on (SSO) allows users to sign in to enterprise cloud applications using their managed Google account credentials, more details here in set up your own custom SAML application. It is also possible to Set up SSO using 3rd party IdPs.
However, Google supports several industry standard protocols like OAuth 2.0, OpenID Connect 1.0 and SAML 2.0 for handling authentication, authorization, and single sign-on. You can take a look at authenticating corporate users in a hybrid environment for more details.

How do I make my end users (under wso2 identity server) subscribe to a api in wso2 api manager?

I am currently doing a PoC on WSO2 API manager (v2.6.0). I am already having a Web application (Ex: Pizza booking) and also registered customers (end users) who is using the application for pizza booking. Now I wanted to bring the backend services of the pizza booking app such as,
Choose store location,
Book pizza,
Track order, etc.
as APIs into the WSO2 API Manager. For this, I would create the required apis in API manager. Then I wanted to bring my existing web application users (end users) into the API manager and provide access to those apis.
What would be the best way to implement this?
Bring my users under WSO2 identity server and use identity server as a key manager to my API manager?
Bring my users under secondary user store/ use custom user store of API manager?
Out in that case, how would I provide access to particular API's (subscribing to API's) without logging to API manager store and subscribing manually for every user?
Also,
What is the use of creating a Service provider and creating an Oauth application under Inbound authentication?
What can I do with this application?
Is this same as the application we create before subscribing to an API in API manager store?
Can I add users to this application and grant access to them in common?
Can I subscribe to API's using this application so that all users under this application will have access to it?
You can do it either way. Using IS as Key manager (if you already using IS), or adding as a secondary user store.
So, if you are already using WSO2 Identity Server in your deployment, configuring it as key manager (by sharing user stores), will automatically enable all the users in IS (with proper permission) to access the apis.
If you do not use the IS currently, the best option is to add as a secondary user store to the existing APIM deployment.
Please find the answers to the other questions below.
What is the use of creating a Service provider and creating an Oauth application under Inbound authentication?
What can I do with this application?
Is this same as the application we create before subscribing to an API in API manager store?
Can I add users to this application and grant access to them in common?
Can I subscribe to API's using this application so that all users under this application will have access to it?
Answer
The Service Provider is created automatically when an Oauth application is created and generate keys. But, there are different aspects of these two entities.
The Service provider is generally used for generating application keys to get an access token to invoke the apis.
OAuth Application (when you create through API store) has several other uses such as subscribing to APIs, enforcing throttling policies for subscriptions etc.
In order to use the token generated by an Application, the respective API should be subscribed by the application. Otherwise, you will not be able to invoke that API although you have a valid access token.
You can subscribe to an API only from the OAuth application created through the API Store.
Your users can use the same OAuth application (which is created via Store portal and subscribed to an API) to generate an access token for them. That is by providing them with the application keys and using password grant type, they can generate token for them
Refer this documentation for more info on the token API and grant types. https://docs.wso2.com/display/AM260/Token+API
Adding to what #Menaka has explained.
Your end-users don't have to subscribe to APIs. Only the application developer has to subscribe and embed the consumer key/secret to their app. Then the application should generate tokens for the end-users using those keypair+end user credentials.

Custom Federation broker on azure and google

What could be an alternative to custom federation broker on aws in azure and google. In AWS I am able to create a url that permits federated user to login and access resources like this -
https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-custom-url.html
How we could create the same in azure and google?
This answer covers Google Cloud Platform.
The basic foundational identity for Google Cloud (GCP) is Google Accounts. This means that the users are required to have a Google Identity before you can setup federation / SSO. GCP IAM permissions are assigned to email addresses (User, Service Account, G-Suite Group, etc.).
Where AWS requires a custom URL for SSO, Google implements OAuth. This means once authenticated, users can just use Google services without needing special URL entry points. In this respect Google's SSO is smoother for end users.
GCP supports SAML 2.0 SSO. Google acts as the service provider and the third party (AD, Okta, etc.) act as the Identity Provider. This requires you to setup Google Cloud Identity.
I went thru this process and just like AWS, it can be complicated. One item to think about. Do you plan to use GCP as your primary cloud plaform or one of the other vendors. The reason is that if GCP is your primary platform, then everything will be a lot easier if you also implement G Suite first. However, if you are a Microsoft shop where you want Active Directory to be your Identity Provider, then SAML is the implementation path. Just be prepared that you will need to setup directory synchronization (connectors). Google has a good connector for Azure Active Directory. This video provides a good introduction to extending Active Directory to GCP IAM.
This article will take you step by step thru setting up the correct Google services, SAML SSO, setting up Identity Providers, etc.
Using your existing identity management system with Google Cloud Platform
Additional Reading:
Google Cloud Identity
Setup SSO
Set up your own custom SAML application

Getting Google IdToken for service account?

I have a backend that is serving android clients, authenticating them with IdToken sent from the android app.
Now, I need to authenticate a service running on aws that is using my apis. So I figured a service account would do the trick, using the private pem file to create a IdToken and send it along just as the android clients do. But I find no way of obtaining an IdToken with these credentials. Is this possible (preferrably in nodejs).
Or am I on the wrong path here?
I know this is older, but I found this question and it didn't lead me to the answer I ended up with.
I followed the guide in https://cloud.google.com/endpoints/docs/openapi/service-account-authentication#using_a_google_id_token with some mix of https://cloud.google.com/iap/docs/authentication-howto, which mentioned that the key to this was to include a target_audience claim in the generated JWT.
So, essentially I made a JWT that looked like:
{
"exp": 1547576771,
"iat": 1547575906,
"aud":"https://www.googleapis.com/oauth2/v4/token",
"target_audience": "https://example.com/",
"iss": EMAIL OF SERVICE ACCOUNT
}
and posted that to https://www.googleapis.com/oauth2/v4/token with params grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer and assertion=<THE JWT>
Without target_audience the endpoint gave me an access token, but with it I got an id_token instead.
Grettings since 2020
I had problems in Java for take ID_TOKEN of a Google Service Account. My project had two years and i were using GoogleCredentials, fromStream method and a JSON credential, but this class didn't gave me ID_TOKEN, only access_token on a not JWT format.
I solved because on this years Google updated here java code for authentication, for take ID_TOKEN you must use this library https://github.com/googleapis/google-auth-library-java
<dependency>
<groupId>com.google.auth</groupId>
<artifactId>google-auth-library-credentials</artifactId>
<version>0.20.0</version>
</dependency>
And then use ServiceAccountCredential
String credPath = "/path/to/svc_account.json";
ServiceAccountCredentials sourceCredentials = ServiceAccountCredentials
.fromStream(new FileInputStream(credPath));
When you create this class, itself will authenticate with google and have a access_token,refreshToken...
For extract ID_TOKEN you must use this function:
String audience = "http://localhost"; //Your server domain
IdToken idToken = credential.idTokenWithAudience(audience, new ArrayList<IdTokenProvider.Option>());
String id_token = idToken.getTokenValue();
And with this you have a JWT token.
I hope this help people like me,that are trying get ID_TOKEN.
You cannot use service accounts generated for Google Cloud APIs to directly authenticate against your own APIs. How will you know which service account private keys are valid and which have been revoked? Google does not expose this information.
Service accounts are rather meant for delegation of credentials. When you access Google Cloud platform service, you will be authenticating with your google account credentials. You will not want to provision the very same credentials everywhere your running code needs to access any of the Google cloud services (i.e. Cloud APIs). Instead you create service accounts whose scope can be reduced to a subset of the scope of your google account credentials. This way a particular piece of code can be limited to only a few set of APIs.
Service Accounts
A service account is a special account that can be used by services
and applications running on your Google Compute Engine instance to
interact with other Google Cloud Platform APIs. Applications can use
service account credentials to authorize themselves to a set of APIs
and perform actions within the permissions granted to the service
account and virtual machine instance.
What are service accounts?
Service accounts authenticate applications running on your virtual
machine instances to other Google Cloud Platform services. For
example, if you write an application that reads and writes files on
Google Cloud Storage, it must first authenticate to the Google Cloud
Storage API. You can create a service account and grant the service
account access to the Cloud Storage API. Then, you would update your
application code to pass the service account credentials to the Cloud
Storage API. In this way, your application authenticates seamlessly to
the API without embedding any secret keys or user credentials in your
instance, image, or application code.
I know where your confusion stems, it is because service account also have the same OAuth model you are used to.
You can use service accounts to get access tokens and refresh them as needed, but the scope of authentication is at the very maximum limited to the surface of the Google Cloud APIs. You will not be able to mix and match your APIs with that.
Alternative is to either build your own authentication model (which is not so clear from your question when you say authenticating them with IdToken sent from the android app) or rely on something like Cloud endpoints which you create and manage APIs along with API keys for authentication.
As you already mentioned in one of your comments, you can follow the Service-to-Service authentication guide which describes how you can use Google Cloud Service accounts to authenticate with your APIs running on Google Cloud Endpoint.
It supports using Google ID JWT tokens. The caller will have to send the JWT to Google Token endpoints to obtain a Google ID token and then use this Google ID token in all of your requests. This approach also has the advantage that you only have to whitelist the Google ID token server in your API configuration.