I am creating an arcade website with multiple games. should I generate a single oauth client id for the entire domain or should I generate a unique oauth id for each individual game?
The more interesting question is: What user experience would you like to give users?
If you want to build your brand across each of the games, you'll configure a single project (ZBestArcadeGames.com, for instance) in Cloud console. Users will be prompted to authorize your entire site. Whether you create one client or multiple clients in this case is not super-important, since you can configure multiple redirect_uris for a single client. Users will consent once to sign-in to your site and they can authenticate to every game w/o additional consent prompts. Similarly, if they revoke access to your site, they will no longer be able to authenticate to any game in the site. This may be the typical choice if your company develops all games it hosts.
If, on the other hand, you want to highlight the individuality of each game and allow users to consent / de-authorize authenticating to them individually you need to create separate projects each with its own brand (and in this case you will need to configure at least one client in each project). This may be the typical choice if each of the games is developed by a company and there's no implied trust between the games you host and your company, and you'd not like to sign terms-of-service on behalf of these other companies--you might even want to ask the developers of each original game to register separately (using the redirect_uri for your site).
Related
I have to build a portal for my institute which will act as a job portal for the institute. Companies should be able to post their job/intern openings on the portal. For that to happen, one prime condition is that HRs should login only with their work profiles and thus their personal accounts(gmail,etc.) should be restricted. I have seen some similar questions where we had to whitelist a particular domain and restrict all others but this might not be feasible in this case, as whitelisting all the work domains doesn't seem practical. Is there a built-in solution for this?
My Tech Stack is:
NextJS for the frontend.
For the backend part, I am thinking of either NodeJS+mongoDB OR Sanity.io depending on a more feasible solution for the above problem statement...
Restrict yahoo/gmail and only allow their company's email or school's email (.edu). You can also have a dropdown of whitelisted school's email or company.
School or companies who wish to join your platform will have to be manually added once. Basically whitelisted list can perform registration in the future.
I am working on a web application which is based on Google App Engine (GAE). The requirement of the application is that one user can be associated with multiple company accounts.
My application has two main types of accounts. One is that main Admin/Company account. Other is the employee account (i.e. the persons who work under a company). Now, what I want to do is that to allow an employee to work under more than one companies, but he does not have to make a separate account for each company. His single account can be associated with multiple companies.
I have explored different platforms which are already supporting this feature. The major ones which I found are Slack and Asana. And my problem can be perfectly mapped to what Slack is doing right now i.e. I create a single account on Slack and I can join multiple workspaces on Slack using this single account.
I want to achieve the same in my application too. I am curious that how Slack is supporting this feature right now? Does it send some ID with every request to the server which indicates that the activity which just has been done is associated with the workspace under this ID? Or there is some unique sort of token associated with every workspace (on Slack API level)?
I do have such a model in my app. A unique auth_token is associated with every company account. So, I am thinking that when an employee wants to do an activity for a specific company he will send this unique token with the request to the server so that server knows for which company the activity was performed.
Does anybody know what is the best way of achieving this?
There are two different concepts at work here:
Relation between account and company / workspace
The data structure for the Slack account is designed such that it can be linked to multiple Slack workspaces, e.g. in SQL you would have a many-2-many relation between the accounts and the workspaces table.
Staying logged in
The way Slack and others Single-Sign-On provides like Google SSO keep you logged in is by settings a browser cookie. That cookie would usually be some kind of crypto hash and the SSO provider will use it to identify to which account the current user belongs to or to request a login via OAuth if the cookie is missing / invalid.
This can also be achieved partly with server sessions (which also uses cookies). Using server sessions is easier to implement than implementing your own (secure) cookie solution, however the user will only stay logged in as long as the browser stays open. But that should be sufficient for most solutions.
Note that tokens for the Slack API work very differently. e.g. they have to be generated per workspace, user and app.
The company I am working at offers a web based calculation tool which has to be paid monthly (a fixed price for a license).
Normally, users go to our website and authenticate themselves with their credentials and then can use the application. When they cancel their subscription they are not able to use the tool anymore, obviously.
Now another company called us because they want to provide our application for their own clients. We have already fixed that they have to pay a license fee for every of their clients. But there is also a restriction: their users should not have to log in on any of our websites (only on the website of our client). But the web application is hosted on our server and is loaded as an iframe.
Now there is that problem that we are not sure whether our client tells us the correct number of people who use our application wherefore we would like to verify that in some way.
One of my ideas is the following:
Our client has to call an API for every users who would like to use our application in order to submit some information like name or an unique ID of that user
When the user would like to access our application, an ID parameter is appended to the iFrame URL
I think that this is not a very good solution because our client could use the same ID for every access and pretend that only one users uses the application. By saving the ip address and id of the accesses it is possible to determine fraud in some cases because ip address will not change frequently.
We even do not have to know WHICH user accesses the application but only the NUMBER of users per month.
I am interested if there is a cryptographic solution where it is hard to cheat. Something like an authentication method which does not require any interaction of the user.
Well you can't. You should require the partner to issue a token for each user so you know they came from the partner.
You could have the partner call an api you expose to issue a one time token for a user and specify user id and IP. You could alternatively have the partner digitally sign such a login request.
If you bill the partner per user, and the partner decitfull he could claim less users.
You can fingerprint the users, you can give long term coockies, you can check IP and fonts installed etc. These will allow you to detect most types of fraud.
If you give a declared userId a cookie and then see him again without it, you assign him a new cookie and then later see the first cookie again while the partner is always declaring same id that is a very strong indicator of fraud.
If I was the decietfull partner I would pair up geographicly close users and merge their IDs. it would look no different from a user with two devices. But this still limits the extent of fraud possible. Two devices per user is plausible. 10 less so.
Find business partners you trust.
Recently google has added multiple user support to the assistant so how would use the API to identify the person by voice?
It depends what you mean by "identify the person".
There is no way for an Action to get the raw audio, so there is no way for it to do voice printing or anything along those lines.
Although each voice has to be reported against a Google User ID, you do not have direct access to that user ID.
What developers do have access to is a UID that is sent along with each request to your fulfillment server. This UID is consistent across requests, although it can be reset by a user (for example, if they reset their Google Home). You can think of this the same way you think of an HTTP cookie - you can track the UID and, if you see it again, have reasonable assurance it is the same user that accessed it last time. This breaks down, however, for the "default" account on Google Home, since anybody who doesn't have an account will map to this user.
Beyond this, you can also use Account Linking to connect a Google Account consistently to an account in your own system. If you have sufficient authentication in place, or are using one from Google or Facebook for example, this can act as an identity.
There isn't an API for developers to identify users by voice.
Imagine a situation where a large corporation wanting to give their users access to a website, without having to individually register each of their users with the target website.
EDIT: Registrations to the website are paid subscriptions, so normally users would pay and get their accounts activated via support line (or it happens automatically). Corporate would want to purchase a bulk subscription, and add/remove the users under that, subject to a maximum limit, so the individual users don't have to go through the hassle.
Users should still have their individual accounts with the website(instead of a single account used by all users) so that they can have their preferences saved, etc.
(Prefer a solution where most of the implementation happens in the website side)
Are there any accepted patterns, solutions for this kind of scenarios?
I thought of if we could use OAuth(Yes, I know it's authorization,
but may be we can use it as an authentication tool as well, right?),
or OpenID like protocol. But the corporation does not have such
mechanism exposed to the outside. Are there any "off the shelf" kind
of products which we could use to create a OAuth/OpenID
implementation against an existing user base, lets say
ActiveDirectory.