# Social Login with Multitenant **URL:** \ **Category:** Get Help\ **Tags:** api, auth0\ **Created:** [October 9, 2018, 8:49pm UTC](https://community.auth0.com/t/social-login-with-multitenant/16528 "2018-10-09T20:49:37Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![sugat](https://upload.wikimedia.org/wikipedia/commons/thumb/7/7c/User_font_awesome.svg/768px-User_font_awesome.svg.png) [@sugat](https://community.auth0.com/u/sugat)\ **Post date:** [October 9, 2018, 8:49pm UTC](https://community.auth0.com/t/social-login-with-multitenant/16528/1 "2018-10-09T20:49:37Z")
Hi, We have an app with multiple tenants with different set of users for these tenants. We are looking to implement Social Login for our app. We want to to implement in way where a new user will be assigned to a different tenants based on the data we receive from Social connection. Once the user is registered, that will always be redirected to the associated tenant. What is the best way to go about it? Thanks, ---
**Author:** ![James.Morrison](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/james.morrison/32/13507_2.png) [@James.Morrison](https://community.auth0.com/u/James.Morrison)\ **Post date:** [January 7, 2019, 6:24pm UTC](https://community.auth0.com/t/social-login-with-multitenant/16528/4 "2019-01-07T18:24:43Z")
Hi there @sugat, I apologize for the delay in response. We had a similar question come up back in April which I will share a snippet it of the response below. However if by chance I am off base at all please let me know and I’ll be happy to dig in deeper. Thanks! > The topic of handling of authentication and authorization in multi-tenant applications is really broad, there are many choices to be made and design decisions that might or might not make sense depending on your needs. I’m going to provide some notes that will hopefully be useful to you, but I wouldn’t consider this complete by any means. > > One of the first design decisions in a multi-tenant app is how you will handle authentication: > > - Will each tenant have its own user base of email/password authentication (e.g. a DB connection for each tenant) or will there be just one source of users (a single connection)? > - will you provide your tenant with SSO capabilities (so that they can authenticate with their own identity provider)? > - Will you provide social login capabilities? > > In your case, you mention that a user can be associated with more than one tenant, so let’s assume that there will be one source of users (maybe one DB connection and some social logins) shared across all tenants. > > In terms of the authentication transaction, the tenant is not relevant when using a shared user base. Using a vanity URL (such as `https://tenant1.app.com` ) migh provide the application a hint of the user intent (“I want to see my `tenant1` resources”), but the identity of the user is the same regardless of the tenant chosen. So, even if you have `tenant1.yourapp.com` and `tenant2.yourapp.com` , you will probably have one common authentication endpoint (e.g. `yourapp.com/login` ) that subdomains will use to identify who the user is when needed (that endpoint will probably do so by redirecting to Auth0’s `/authorize` endpoint, and this might all happen in a popup window to ease state management). Once you know how the user is, and when the user is back at the subdomain, you would know if the user is authorized or not to the tenant. But that’s something that is better handled at the application level, not in a rule (e.g. “You tried to access `tenant1` , but you are only authorized to access `tenant2` and `tenant3` . Which one would you like to use?”). > > If you had different user stores for each tenant, the situation would be different, as you would require a hint to know which directory of users to use when authenticating. In this case, the `login_hint` parameter in [OAuth2](https://auth0.com/blog/oauth2-the-complete-guide/)comes in handy. > > Then there’s the matter of **authorization**. You mentioned that each user has a different set of permissions for each assigned tenant. Most likely this will be a set of roles, but that’s completely up to you. Imagine that in your backend, somewhere, you have this information: > > ```auto > { > "user": "user1", > "tenants": [ > "tenant1" : { > "roles": ["full admin"], > }, > "tenant2": { > "roles": ["user", "moderator"] > } > ] > } > > ``` > > That is information about what the _user can do_ . You can do all authorization decisions _in the backend_ , with just a bearer token that has the user id as a claim (plus the usual expiration, audience, issuer and signature, of course). > > Imagine an access\_token that simply has this information about the user: > > ```auto > { > "sub": "user1" > } > > ``` > > And your SPA would make a request to your backend API: > > ```auto > GET https://yourbackend.com/tenant1/api/posts/450 > > Authorization: Bearer xxxxxx > > ``` > > In this case, as the token only identifies the user, your backend will need to check `user1` 's permission, to see if she’s allowed to access `tenant1` and, in particular, if she can read post 450 (or whatever). If you expect permissions to change on-the-fly, then that’s the model you are after. > > You could put permission information in the access\_token about what the user _can do_ , but that be simply an optimization. You can write a rule that checks the user permissions somewhere, and use custom claims to convey this information _in the access\_token and/or id\_token_ . Something like this (I’m simplifying here for easy reading, but you would need to use namespaced claims): > > ```auto > { > "sub": "user1", > "roles": "tenant1:full_admin tenant2:user tenant2:moderator" > } > > ``` > > At some point, putting all the permission information in the token becomes unmanageable, especially when a user has many tenants assigned and/or much granularity in the permissions (you end up with a big token). Plus, you will have to live with the fact that access\_tokens have a certain validity time, and decide if you are willing to live with that compromise (what if permissions change while the token is still valid?). > [@Multitenant application - identifying the tenant during login](http://community.auth0.com/t/multitenant-application-identifying-the-tenant-during-login/11025): > > Hi, I am evaluating auth0 as a possible authentication approach for our app. Trying Lock for authentication. Our app is a SPA + WebAPI, with a multitenant concept. Each app user is assigned to one or more tenants. For each assigned tenant, the user has a particular set of permissions. A new tenant is automatically created when a new customer sign up within our app. When a user access our app, the tenant is identified by the subdomain of the url, such that before the user logs in, the app alread… > **[Multi-Tenant Applications Best Practices](https://auth0.com/docs/get-started/auth0-overview/create-tenants/multi-tenant-apps-best-practices)** > > Describes best practices for how to use Auth0 to secure your multi-tenant applications. ---
**Author:** ![James.Morrison](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/james.morrison/32/13507_2.png) [@James.Morrison](https://community.auth0.com/u/James.Morrison)\ **Post date:** [January 21, 2019, 10:24pm UTC](https://community.auth0.com/t/social-login-with-multitenant/16528/5 "2019-01-21T22:24:45Z")
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.