We're developing one web application which has multiple user types access Google APIs via OAuth 2.0.
Is it possible to set up different consent screen settings for different user types. For example, user of accounting department will see product logo and product name of accounting.
No there is only one consent screen per project. You can't change it programmatically either. Your only option would be to create different project with different consent screens, but then you would have a problem with the fact you will have different Client_id's and they wont mix and match.
Related
I have a use-case where I need to use apple login on two application (one has a iOS mobile app also) which belong to the same company but have different logos, is it possible to use the same apple login service in both. More specifically I had an issue with apple private relay with hide my email, as the accounts were duplicating on my iCloud profile. Is there way to link those two client_id so they don't create duplicates.
I've checked the apple documentation but it doesn't cover this topic.
We have an instance of IdentityServer4 running and use it internally for our apps. Those app clients have the property RequireConsent set to false. The result is, you go to the apps website (app1.website), you are redirected to the identity server website (identity.website), where you log in, and redirected back to app1.website.
We also allow 3rd parties to build apps or integrations against our system. In their case, every user needs to approve the app on a consent screen, before they can get the refresh token for that user. There are 2 ways this can play out:
The 3rd party has a user management on their own, in that case they only need 1 user who initiates the connection, and this user's token is used for every further interaction with our system.
The 3rd party doesn't have their own user management, and instead relies on our identity server to authenticate users. This is something, we want to encourage more in the future, as it helps our partners to build their apps faster, since they don't need to deal with the whole user flow, like confirm email, forgot password, ...
However, the problem in option 2 is, that our app (which is B2B) has a user structure that is similar to slack. When one user in an organization approved an app, others should be able to use it without the need for a consent screen (especially since not all users are allowed to approve apps).
In the current scenario, if the organization owner, Alice, approved the 3rd party app X and told Bob to use it, Bob would still see a consent screen. If Bob were also an organization owner, he could approve the consent screen, but if he were just an intern in the company, he wouldn't be able to use the app X.
What I'd really want is to approve a 3rd party app on an organizational level. In azure active directory, what I'm looking for seems to be called Tenant Admin Consent. There is a similar question How do I trigger the admin_consent flow using IdentityServer 4 for a multi-tenant app? - however, We aren't using IdentityServer 4 as a middleman, but it's the final user management instance.
How can I configure / extend IdentityServer4, so that if the second user, from the same organization, tries to use an app, their refresh token will be automatically generated, without a consent screen?
Update: It's not about replacing Option 1 with Option 2. Big providers will keep their custom user management. But small app providers should be able to re-use our user management features. Once an app is "tenant wide" connected, any user from that tenant should be able to access it, as if the app config was RequireConsent=false (other tenants would still need to connect it with a consent screen first)
We're developing a Rails app that will serve as a backend for multiple apps. The Rails app will have a web CMS that will let admin users to manage their mobile apps (one admin user can have 1..N mobile apps).
The same Rails app will also serve as an API for those mobile apps. The mobile apps are completely separated one from each others, not sharing any data among them. We have users with different roles (global_admin which manages his app in the CMS, place_manager which manages his place in the app within the CMS, and users of the mobile app). These users are not shared between apps (if a user signs up in a mobile app, he will be able to log in only in that app; so if he wants to log in another mobile app he needs to register again).
Which is the best approach to achieve this? We are thinking about:
Option 1: we can have a single User model, with different roles on different apps (global_admin on app 1, user on app 2, manager on app 3...). If a user signs up for app 1, a record is created, and if he signs up for app 2, we only add a role to it, but he thinks that he created a new account.
Option 2: we can create a record for each user on each app (removing the uniqueness constraint on the email field)
Option X: ideas?
Thank you in advance
The API/API users scenario looks like a situation for multi-tenancy in which each app runs as a separate instance. You can look at something like Apartment for database level multitenancy, or Milia for app level multitenancy.
Database level is generally easier to manage, but you will need a workaround for the global admin requirement.
I suggest the following approach if you would like to use a single rails application for multiple mobile apps.
For users you can have different API returning different kinds of users, specific to the application requirement.
Use STI to differentiate users for each apps(in this way, you could have only a single table for users but different models)
These users are not shared between apps (if a user signs up in a
mobile app, he will be able to log in only in that app; so if he wants
to log in another mobile app he needs to register again).
In my opinion these are three different Rails apps. Obviously the apps have nothing in common, in particular no data is shared.
I think Option 1 would work well in your case. You can setup a has_many :through relationship between apps and users that will contain information regarding the user's role for that particular application (assuming only one role per user per application).
With this approach the workflow would be a bit different than what you describe though. If the user is not registered at all (i.e. no record with that email exists), they will need to signup (email + password) at which point you'll create the user record (with hashed password) and setup the association to the mobile application. If the user IS already registered, you don't want them entering a new password again, you'll simply want to setup the association. This can be handled via first_or_create. Hope this helps.
I have a web form that our HR department uses to add new employees. It adds them to the database, inserts them into Active Directory, and a few other things. We would like it to also create their Gmail account and subscribe them to groups (our current users are already in Gmail under our domain).
Everything I find requires OAuth2 for this, yet it seemingly requires a prompt. "Google displays a consent screen to the user".
Is there a way to do what I want behind the scenes without any sort of prompt?
I want to give users of my iPhone app the option to publish a story to their Facebook walls. Does this require that the user be presented with a sign on screen, and then a second screen authorizing the wall post or can these two screens be somehow combined into 1?
The sign on screen will let user key in his credentials and thus allowing your application to access the information. You might like to read Extended Permissions for Facebook API for iphone.
You will need to open a dialog box right after he logs in to allow your application to access.modify content on his profile (like publishing a story). I am afraid If these two screens can be combined into one.
You can also refer to http://www.capturetheconversation.com/technology/iphone-facebook-oauth-2-0-and-the-graph-api-a-tutorial-part-2