I'm trying to build an application similar to Spotify, where users can access particular content if subscribed. I'm trying to use Microservice Architecture to build this. The client is an android app.
So for user Authentication, I have an "Account Service". It makes use of the Oauth2 code to authenticate the user.
For accessing content, I've made a service called "content service" which would authorize user access to content, thereby giving them a signed URL to the content (link to .mp3 in this case).
Now, how do I authorize the user requests at "content service". All subscription details are stored in the "Account Service" database. I don't want it to communicate with account service, as that'll defeat the purpose of using microservice architecture.
so to solve this, I was thinking of making use of digital signatures. Have the account service generate a key pair, send the public key to "content service" or some other Keystore service. specify the access/authorization in JSON, sign it, and send it to the client. When a client wants to access any content, it sends this signed JSON to the "content service", which checks its validity by making use of the key "Account Service" sent earlier and thus authorizes the user and grants access.
I want to know a better/standardized way of doing this.
Related
I couldn't find documentation describing the auth flow of the bot.
Could you please point me to it and/or describe it?
What I am interested is if the context that I get in TurnActivity can be trusted or not?
In other words, can I be sure that the message I received is really from the user with the given ID and email, or can an attacker spoof that message altogether and send it to my bots rest endpoint?
Goal
Why I am asking is that I will get users to login to a 3rd party service and associate their token to access the date in 3rd party service with user in teams that I get from message context.
The data in 3rd party service is secret so should not be possible to access for other users.
My question is when we get the REST call on our botframework message endpoint if the context comes as part of say JWT token that the SDK verifies against Microsoft identity provider and hence cannot be faked. Or is it just a simple field in body of the call. In the second case it would be pretty easy to fake the context and then through the bot get access to protected data.
How to send service emails
from my backend with smtp.google.com or Gmail API while making sure
the secret stored on the backend server can only be used to send emails from a specific sender?
Goal
send user account activation emails from my backend
use smtp.google.com or Gmail API (i.e. no own SMTP server)
authenticate with OAuth2.0 (i.e. don't enable "less secure apps")
Current state
implemented the email sending part
for testing, I created a noreply#**.** Google Suite account
for testing, I generated an accessToken via OAuth2 Playground
using the accessToken I can send emails via smtp.googl.com
Problem
Google suggests to use a service account for this
But to send emails from no-reply#x.y I have to enable Domain-wide Delegation
Domain-wide delegation allows to impersonate every domain account
the secret stored on the backend should only allow to send mails from no-reply#**.**
Lets start with send user account activation emails from my server I am gong to assume that you have a web app. This web app allows users to register with your system. Now when a user registers with your system you want to automatically send them an account creation email. Your idea is to use Google rather than setting up your own smtp server and sending these emails from your own system. Not a bad idea really.
Lets think about this for a minute the emails would need to be sent automatically so you need some kind of service sending them. To do that you want to use a service account. Again this is a great idea using a pre authorized service account that you will not need to have a user to authorize the app.
The only issue is that service accounts do not work with normal gmail accounts. To use a service account with Gmail api you need to use a google workspace domain account. The workspace domain admin would then be able to add permissions to the service account letting it act like a user on the domain. In this case your idea of no-reply.
So your workspace domain account would have a user called no-reply. The domain admin would then configure domain wide delegation to the service account allowing it to pretend that it is the user called no-reply. For all intents and purposes the service account is the no-reply user. It will be able to send mails as if they are coming from that user.
For all this to work you will need the workspace account with that user.
Have a look at the following link, it's actually one of Google's better examples it shows how to set up the delegation.
Perform Google Workspace Domain-Wide Delegation of Authority
Here you create a service account with credentials, allow this account to impersonate other users (e.g. the no-reply user), to only use the Gmail API and to only use it to send emails.
the documentation is a bit outdated, you can skip the step Grant users access to this service account and create the service account key afterwards via the service account edit function: Manage keys
in the step Domain wide delegation you need Google Admin not the Google Cloud Platform Admin Console as in the previous step
Just remember to swap out the lines about
https://www.googleapis.com/auth/admin.directory.user,
https://www.googleapis.com/auth/admin.directory.group
and use
https://www.googleapis.com/auth/gmail.send
instead as you want to access the Gmail API and only allow the service account to send (not read) emails
tip
in the sample code in that link
.setServiceAccountUser(userEmail)
userEmail is the email address of the user you want to impersonate in this case no-reply#x.y
So I guess what I am saying is that what you want to do is definitely possible, however, it may be easier just to set up your own SMTP server.
I have API backend and it will be consumed by different consumers like our own company website and even other website can use our API with certain quota/limitation and for this scope management we will be using express-gateway(eg), however this is not the only reason I am using express-gateway(eg). Now coming to my problem/miss-understanding, for our own website we can create api-key and user credentials using eg command. But for the other user who wishes to use our api, I don’t want them to contact me for this integration, rather they should be able to create a user credentials and API key themselves using some facility (let us call it key management) provided by us. Here I am stuck how to give a web platform or any other mechanism where a user can create account and then create api-key for their own website. I was thinking to extend the express-gateway app itself and create page where a website owner can fill the form with various input field that will serve as parameter for eg command and I can trigger eg command in node console and create credentials and save it in redis database and then fetch those information to show it to user as their use rid and api-key. But I want to know the best way how others are doing, like how google, twitter and many more are allowing to create api-key, delete key and regenerate the api-key on compromise. Some suggestion would be to use third party tool to manage user-credentials, I will have little inertia to accept that, even if I do so how will I hook those third-party solution to my express-gateway.
In general, API gateways and authentication servers are independent, or at least loosely-coupled. The typical workflow is:
A user browses to the Create Account page for a service.
The user creates an account with the authentication server
The user makes a request through the API gateway
The API gateway checks with the authentication server whether the operation is allowed, discarding it if the user is not authorized to perform the requested action
The API gateway dispatches the request to the appropriate server
The receiving server checks whether the user is permitted to perform the action (in case the API gateway has been compromised)
Express Gateway includes its own authentication server for convenience, but the steps are basically the same. The difference is that one uses the Express Gateway Admin API to create the user and credentials rather than going to a different server.
Note that Express Gateway and its default account database (reddis) are not persistent out of the box.
I want to build a web application in Go. I'm using Google App Engine for deployment combined with Identity Aware Proxy (IAP) to authenticate user access.
I want to know how to access the authentication to get the user email, which I can link to app data stored in a back end database. Essentially I want to avoid my users logging in and then having to authenticate again to get their profiles from the back end.
I have looked into the IAP documentation and I can see it uses JWT Headers and that is where my knowledge lacks. My guess would be a link to the incoming request which accesses those headers to get the email.
With Google service accounts, Google generates the public/private key pair associated with the service account and passes that along to the end user who wants to make API calls. And its up to the end user to keep the keys safe. Is it possible to generate a service account and an associated client, but provide a certificate that Google can use to validate the service account client making the request? The problem I'm trying to solve is not to exchange any private keys.
Also is it possible to scope the users a service account has access to? For example if I wanted to create a service account that only has impersonation api access rights on a sub set of users on the Google domain. From what I've read if you create a service account with domain wide delegation, the service account has impersonation api rights for ALL users on the domain.
No, you cannot associate service account and provide a certificate to validate the client request. As stated here a service account's credentials is unique and at least one public or private key pair. To generate service account credentials, go to Google Developers Console. In the Create service account window, type a name for the service account and select Furnish a new private key. Your private/public key pair is generated and download to your machine. It serves as the only copy of this key. You are responsible for storing it securely. For more details about service account credentials in the Developers Console, see Service account in the Developers Console help file.