I am working on a multi tenant guide. Thank you very much for your feedback; I'll make sure to include it.

As you continue to build out your multi tenant application, please continue to post on the forum about your progress and/or any other questions.

We often hear our multi tenant support is a differentiator for FusionAuth, and would love to make it easy/clearer for everyone.

Great explanation, and you're absolutely correct that I don't/shouldn't want to persist the access token in the web api. With your help and a lot of grinding I believe I have this figured out. One of the biggest hurdles was my misconception of how multi-tenancy works in FusionAuth. I thought that one application could be shared across multiple tenants but they cannot. Not a big deal because applications can be easily created with your APIs. Just as a suggestion, maybe the FusionAuth documentation could make this a little more clear for others who are exploring your offering.

Thanks for your great support!

It sounds like you are on the right track. A few comments:

• The Web API should not persist the access token, but the web app definitely can (often in a session). The web app can then present the access token until it expires, in which case the web app can renew the access token with the refresh token.

• "Web API verifies token against FusionAuth (my app) endpoint" -> You can also verify the claims were signed by FusionAuth without calling the introspect endpoint by using a JWT library.

• "Web API pulls user claims from token for role(s) and tenant, if verified returns data back to web app." -> Makes sense. Make sure to check the "aud" and "iss" claims to ensure they are what you expect. You should do this even if you are using the introspect endpoint.
• The correct tenant can be found from the client_id, since all applications are associated with one and only one tenant.
  If you have any specific issues, please feel free to post them in the forum (a new topic might be best).

By the way, if you are running in FusionAuth in production at scale, we encourage you to get a support contract . Having one allows access to the engineering team via opening support tickets. https://fusionauth.io/pricing/. Obviously, this is not a requirement, but should your business needs require a higher support level, it is available

I hope this helps!

Along with the web app, I have a backend ASP.Net Core Web API that is secured with Authorization that the web app is accessing. I need to be able to verify that a user is authenticated, is assigned to an appropriate role, and which tenant they are assigned to before allowing access to the api.

Currently, I am trying to use the following auth flow:

• user is navigated to login page for specific tenant on web app

• click login button and authenticate to FusionAuth (my app) auth endpoint

• web app receives authentication token for user

• web app exchanges auth token for access/refresh token at FusionAuth (my app) endpoint

• web app makes call to Web API passing access token

• Web API verifies token against FusionAuth (my app) endpoint

• Web API pulls user claims from token for role(s) and tenant, if verified returns data back to web app

• Additionally, web app and Web API persist auth access/refresh token for future calls to the Web API so user doesn't have to repeat auth on subsequent calls, barring token expiration

I'm sure I'm making this harder than what it is but I've not used FusionAuth before. Mostly, it seems that the difficulty is coming from the the fact that I'm using multi-tenancy in FusionAuth, otherwise it would be pretty straight forward. I've used this pattern with Azure AD B2C, however that doesn't readily support multi-tenancy which is the the main reason I'm trying to use FusionAuth's multi-tenant support.

Hope this helps you to better understand what Im trying to achieve. It is definitely possible I'm approaching this all the wrong way, so I value your input.

Thank, again.

OIDC is a specification - essentially it is a "thin layer" built on top of the OAuth2 protocol which formalizes identity thru the use of JWT's.

This is important because it means you have the ability to use our standard clients to integrate your application. Or, you could use any other library that supports the OIDC spec and it would be compatible with the relevant FusionAuth Integration Points.

A few thoughts:

1. Are you looking to add third-party OIDC identification? If so, this should point you in the right direction. OIDC documentation with tutorial
2. A small bit about our integrations.
3. Here is a listing of our available client libraries.

If you had a few more details about where you are looking to go with OIDC after reviewing/implementing the above, I would be happy to see how else I might assist.

Thanks,
Josh

It has been a few days but I'm still working on this project. I've looked at this example on FusionAuth: Securing an ASP.NET Core Razor Pages app with OAuth that uses an OIDC configuration. On the surface this looked like the solution l needed, however I have FusionAuth deployed on FusionAuth Cloud with multi-tenants and the configuration in this example doesn't seem to show how to support this in the OIDC configuration. Any suggestions on how to proceed?

Thank you.

Thanks for the additional information! Our recommendation for mobile applications is to use an OAuth workflow similar to what is offered here. What this would mean practically, is that a mobile application developer would open a web view to authenticate/login with FusionAuth.

What this workflow (above) provides, is the security delegation benefits of the OAuth protocol. Using this workflow (OAuth with a webview), user credentials are never stored/collected in the developer's mobile application but are instead stored/collected by FusionAuth. Additionally, FusionAuth offers the ability to theme your login page to style exactly like your mobile application (creating a seamless user experience).

An example from a similar domain would be Financial Services. For instance, if one collects a user's payment information for a service/product, ideally you would never store/collect/handle a credit card number, address, etc, but rather rely on a service like Stripe or Square to securely store/collect/handle that information. FusionAuth offers a similar solution for password/credentials through an OAuth2 protocol.

There are other workflows FusionAuth integrates with here. To enable these workflows you will want to make use of our client libraries. We are always looking to increase the number of example applications to give users more ideas on how to integrate FusionAuth with various workflows.

It is not my intention to be offputting, but my domain expertise is specifically related to FusionAuth. If you select a workflow/architecture to use with FusionAuth and you are having trouble understanding which endpoint to hit in our API to log a user in (for instance), that would be a good question to ask in this community. More in-depth architecture and integration support is certainly possible but would require an enterprise-level service contract from our Professional Services team and/or paid support account to be able to better understand your problem space and tech stack.

Let me know if I have misunderstood your request; I hope this was helpful. Best of luck!

Thanks,
Josh

Let me try to clarify, this is a native mobile app for iOS and Android (actually Xamarin x-platform), so the mobile user isn't logging-in to a website.

Further, both the web client and native mobile app will be accessing an ASP.Net Core web API for interfacing with a multi-tenant (db per tenant) backend hosted on Azure. This API is using authentication and authorization and it is really what I need to secure.

In short, I'm exploring the use of FusionAuth because of its multi-tenant authentication support and need to know where to start with implementing the authentication workflow using FusionAuth. Thus far, I've seen a lot diagrams and general explanations about this on FusionAuth's website but no actual code on how to do it, especially related to native mobile apps.

Any further help would be much appreciated.

Thanks for your question! I want to confirm a few things.

Is this what you'd like to have happen?

1. user visits site.com and signs up on their desktop
2. user installs site.com mobile app
3. user logs into site.com mobile app with the same username and password

If so, then this easily supported by FusionAuth, as both the web and the app could be talking to the same FusionAuth instance, with the same unique application that the user is registered for (on both mobile and web-based views).

If you are instead seeking this workflow:

1. user visits site.com and signs up on their desktop
2. user installs site.com mobile app
3. user logs into site.com using desktop
4. user is automatically logged into the application on mobile app (due to step three)

This workflow is difficult to achieve. Single Sign-On allows for the web client to have a single sign-on for multiple applications on a web/desktop browser using an SSO cookie. Single Sign-On does not, however, easily allow the mobile applications/iphone app to share an SSO cookie with a web/desktop application to allow a seamless signing-in/logon between them both.

I hope this helps!

Thanks,
Josh