Overall flow
I'm working with Google Cloud Platform (GCP), Google Apps Script (GAS), and the Pub/Sub service within a Google Workspace domain environment. This is the flow of requests/data, which works but clearly has auth issues:
GCP Pub/Sub service receives messages for a specific topic
Pub/Sub forwards the message to a push endpoint URL by POST
The push endpoint is a doPost() function within Google Apps Script (GAS), published as a Web App
Details
I have enabled authentication for the Service Account used in the Pub/Sub delivery type options, i.e. Pub/Sub signs a JSON Web Token (JWT) and sends the JWT in the authorization header of the push request. Edit: The Service Account (Client ID) has a domain-wide delegation for the Scopes
https://mail.google.com/
https://www.googleapis.com/auth/drive.scripts
https://www.googleapis.com/auth/drive
Web App deployments come with two options:
"Execute as"
Me (name#workspace-domain.tld)
User accessing the web app
"Who has access"
Only myself
Anyone within {workspace domain}
Anyone with Google account
Anyone
Right now, the web app executes as Me with Anyone having access. And it works.
Problems
The push endpoint is publicly accessible, but should not be. (1)
Follow-up: "The push endpoint must be a publicly accessible HTTPS address" (source) anyways, so "Who has access" will be set to "Anyone" by design.
Limiting the "Who has access" option to "anyone within {domain}" leads to unacknowledged messages inside the Pub/Sub subscription, doPost() will not run, but the endpoint returns straight 40X HTTP codes (probably forbidden).
--> Question: How can I promote the Service Account to being seen as a user within the workspace domain, so it has access to the endpoint?
The push endpoint should validate tokens sent by Pub/Sub. (2)
In GAS, doPost() has no access to (authorization) headers sent to the web app endpoint URL (unfortunately and as far as I know). However, ScriptApp.getIdentityToken() gets an OpenID Connect identity token for the effective user, if the openid scope has been granted.
--> If problem (1) was solved, is it possible to authenticate and authorize the messages send to the endpoint within the GAS doPost() function using ScriptApp.getIdentityToken()? From my understanding, the Service Account should also become the effective user, i.e. "Execute as" = "User accessing the web app".
I might be missing something. So, thanks for any tips and advice!
Doc links
Google Apps Script: Web Apps
https://developers.google.com/apps-script/guides/web
GAS: ScriptApp.getIdentityToken()
https://developers.google.com/apps-script/reference/script/script-app#getidentitytoken
Using push subscriptions: Authentication and authorization by the push endpoint
https://cloud.google.com/pubsub/docs/push#authentication_and_authorization_by_the_push_endpoint
Related
Here's my setup. I have a NodeJS express server providing endpoints and hosting my frontend which I've built using React. I have the Spotify client id & secret stored in a .env file which the frontend references, and therefore publicly exposes.
Currently, for users to link with Spotify, the frontend can redirect to Spotify's authorize page and pass the client id and secret (and a redirect uri) in the url params. They then log in with their Spotify credentials and accept my app's terms. Then Spotify then redirects them to the provided redirect uri, which is just another page of my React app. The user's refresh token is passed as a url param for my frontend to receive. It then sends refresh token to my server using one of my endpoints and I store it in my database under their account.
This works fine, except for the fact that my app's client id and secret are publicly exposed through my frontend. I'm trying to work out a way to allow users to link with Spotify without having the frontend know this information, because if it leaks then people can make calls to Spotify's API on my behalf. But I can't seem to get around the fact that the client's browser needs to at some point have access to something like this.
const url =
'https://accounts.spotify.com/authorize?' +
querystring.stringify({
response_type: 'code',
client_id: spotify_client_id,
scope: spotify_scope,
redirect_uri: spotify_redirect_uri
})
window.location.href = url
I'm new to web development so there may be something obvious I'm neglecting. If anyone has any ideas, I'm all ears. Thanks in advance!
In this particular scenario, you’ve designed around the entirely wrong OAuth flow for the job. Client credentials-style authentication/authorization is not intended to be used in the manner you describe, for the reasons you describe. Instead, you should be using the offered authorization code with PKCE flow, which provides similar functionality for web apps, etc. without necessitating the exposure of your sensitive authentication secrets.
Spotify is pretty explicit about this in their documentation (emphasis mine):
Which OAuth flow should I use?
Choosing one flow over the rest depends on the application you are
building:
If you are developing a long-running application (e.g. web app running on the server) in which the user grants permission only once,
and the client secret can be safely stored, then the authorization
code flow is the recommended choice.
In scenarios where storing the client secret is not safe (e.g. desktop, mobile apps or JavaScript web apps running in the browser),
you can use the authorization code with PKCE, as it provides
protection against attacks where the authorization code may be
intercepted.
For some applications running on the backend, such as CLIs or daemons, the system authenticates and authorizes the app rather than a
user. For these scenarios, Client credentials is the typical choice.
This flow does not include user authorization, so only endpoints that
do not request user information (e.g. user profile data) can be
accessed.
The implicit grant has some important downsides: it returns the token
in the URL instead of a trusted channel, and does not support refresh
token. Thus, we don’t recommend using this flow.
It may go without saying, but since you’ve already elected to publicly publish your app secret, you should consider it compromised and invalidate it immediately before malicious actors are able to indeed use it to craft abusive API requests.
Related to Security Cloud Run services for end-users and other services
I'm using:
Firebase Auth to generate id tokens for users with Google, Microsoft, GitHub ... identities
Cloud Endpoints on Cloud Run to invoke (Cloud Run) gRPC services
Firebase Auth users are auth'd by one of my services
Where I'm struggling....
My app provides 1 or more Cloud Run services that the app's users should be able to curl. But authenticating Cloud Run services require per-service id tokens; the id token's audience must use the Cloud Run service URL and the Cloud Run service URL is service-specific.
It seems as though I ought to be able to exchange the Firebase Auth id token for (Google Account) id tokens (with appropriate audiences) that can then be used to invoke the Cloud Run service. The proxy could also run on Cloud Run and it would use my app's auth service to verify whether the id token user should be issued with a Google id token.
Guillaume Blaquire's answer proposes either Coud Endpoints or a proxy similar to what I describe above. However, Cloud Endpoints requires that the backend services be known at deploy time (which these Cloud Run services won't be) and I want to provide the user with the id token so that they can use curl or some other tool to make the auth'd request.
Cloud Run has some compelling documentation for Authenticate (sic.) but I want something between:
Authenticating users -- I have the JWT but I want to receive a Google id token for the Cloud Run service
Authenticating service-to-service which Guillaume's alternative proposal in the answer.
Rather than place your Cloud Run behind Cloud Endpoints, where you have to know the Cloud Run instances ahead of time, you can handle the request and authentication inside the Cloud Run instance itself.
To be able to handle Firebase Authentication tokens inside the Cloud Run instance, they must be setup so that they can be invoked unauthenticated. Then, inside the Cloud Run, it should launch a web server, parse the incoming request (paying attention to the Authorization header - Firebase Auth sample) and then either action or terminate the request.
To achieve this, take a look at this thread for details on how you can handle both HTTP and service-service requests. Alternatively, you could just deploy the Functions Framework image from which that thread's code is based.
If you want cleaner URLs, host multiple endpoints within a single Cloud Run instance and then place that instance behind Cloud Endpoints or you can take a more manual approach via a custom domain using a service like Firebase Hosting.
I am using Microsoft Bot Framework to build a bot that receives messages from a user and then connects to a a banking service he already registered. (In case you don't know Bot Framework, is just a Web Api where you post messages and it answers you according to the behaviour you specified in advance).
So the banking service knows his user and password. And let's say it also knows the user Skype's username, because the bot will be connected to a Skype Channel via Bot Framework Connector.
My question is: how can I authenticate (in the banking service) the user that sending messages to the bot? The idea of this is of course not to make the user send his credentials (user and password) via messages.
Making the bot send a link where the user can write his credentials and then trigger a callback is not an option. I need to make the authorization flow the most transparent I could do it for the user.
The only examples I currently have of Auth involve invoking a browser for the authenticating service where the user can enter their service-specific credentials, such as Mat Velloso's AuthBot sample on github: https://github.com/matvelloso/authbot
I assume your last statement means this isn't a valid option?
I'm working on a personal project composed of an API and 4 clients (web, android, iOS, windows phone).
I'm using django-rest-framework and oauth2 toolkit on the API side and I wonder which grant_type would be more suitable in my situation.
I read somewhere that the implicit grant_type is appropriate for working with mobile clients.
I'm currently using the resource owner password credentials system.
My current workflow is:
The user creates an account on the API registration page (http://mysite/api/register) then gets redirected on the web client.
The user have to authenticate himself on the API from the web client (the secret and client ID are store in the web client). If the authentication is successful the access_token and refresh_token are both stored in the user session.
Each time the user want to access a page I verify if he is authenticated by requesting the API using his access_token. If the request fails, I retry with the refresh_token. If it's fails again I redirect the user on the auth page.
The user can use the API on a mobile client with the same account without extra manipulations (the secret and client ID are store in a secure location ex. share preferences or keychain)
I like this workflow, it's simple and convenient for the user: he registers once and can use all the clients and I get a perfect separation between the logic (API) and the UI (client). But I'm worried about the security of this system. I don't want to expose my users to threats. Do you guys have any thoughts, recommendations, suggestions?
You help in this matters would be very appreciated.
Thanks in advance!
I'm developing a common auth service for several different web services. The general idea is that a user goes to one of these web services and clicks on a login button and gets redirected to my auth service. Once authenticated, the auth service redirects the user back to the original web service.
To begin with, the auth service will use Google's OpenID Connect service. One idea I had was that when a user was authenticated using Google I could pass around the resulting JWT to other services to use as an auth token. Google mentions this idea in their documentation (https://developers.google.com/accounts/docs/OAuth2Login#validatinganidtoken):
One thing that makes ID tokens useful is that fact that you can pass them around different components of your app. This can be helpful because different components of your application may pass the ID token between them and use it as a lightweight authentication mechanism authenticating the app and the user.
Can anyone help me with the actual details on how this should work e.g. How do I handle log outs both on Google and from the auth service? There appeared to be some documentation on this in older OpenID Connect Session documents (-03) but it appears to have been removed.
You should not pass the ID Token that you receive to Google back to the app to use as an auth token. The ID Token will have an audience specific to your app, not the ultimate client.
If you just passed this back to clientA, then you would open it up to auth attacks where clientB could obtain an Google ID Token via your auth service and then use that token to gain access to user data in clientA.
A much better approach would be to mint your own ID Token and provide an audience designation for each app that uses your service.
Monitoring session state is not as straightforward. The easiest thing to do is for your service to wrap G+ sign-in libraries and interface with the session state api's.
https://developers.google.com/+/web/signin/session-state