List of auth use cases

[mooreds]

List of auth use cases

Description

We know there's a lot of ways to use an auth system. Please comment with a short paragraph describing how you are using your auth system. We're thinking about collating these up and publishing them.

[mooreds]

Centralizes user auth system

My company has customers and employees. The employees have access to some applications we've written (custom SaaS app) and some off the shelf software (nodebb). The employees have access to the same apps as the customers, but also additional SaaS applications (like Zendesk, Quickboos, AWS, and Github). Different employ ees and customers should have different levels of access, and I want to be able to easily provision and deprovision new accounts.

[mooreds]

The Auth bottleneck

My company has users. These users have different applications they need to access (custom applications, open source tools). They also have multiple different ways of authenticating. Some want to use google, others github, others email/password. I want one place where everyone can authenticate and I can enforce role based access control as well as password rules.

[mooreds]

The Auth facade

My company has an application which I deploy on-prem or in a private cloud. I know that my application's users will have different levels of permissions but also will need to federate into my customer's auth solutions (whatever they are). But my engineering team wants to code against a standard auth interface, not against all the solutions we support. We also want the auth portion of our product to be easily configurable by admins on the customer side.

[mooreds]

Microservices API gateway

My company's application is microservices based. I want to have one central, performant chokepoint where all requests are sent, and then have the gateway check for authorization and authentication. If the request is valid, I want the request forwarded on to the appropriate microservice.

[mooreds]

Single sign-on

You have two different websites (websitea.com and websiteb.com). You want your users to be able to login to websitea.com and then, when they visit websiteb.com, be logged in without any effort on their part.

[mooreds]

Private label SaaS user management

You have a software as a service product. You want to be able to offer a private label service for a premium price. So your saas for the public might live at saas.com but your private label SaaS might be branded and live at saas.company.com or saas.organization.org. You still want to have one view of all your users and be able to manage them from one admin ui, while ensuring that users from saas.com can't login to saas.company.com and vice versa.

[mooreds]

Controlling access to resources on authorization

You have network, hardware or other resources that you want to control access to (a wifi hotspot, for exampel). You can do so via software. You set up users in an auth system and then on successful login you enable access to the resources via the program calls.

[mooreds]

Device authorization

You have a device with limited input capabilities but want to grant permissions for apps running on the device to connect to other APIs or services on your behalf. The auth system should enable this. Note, explored more fully here: https://fusionauth.io/learn/expert-advice/oauth/oauth-device-authorization/

/ht @jerryhopper.

[mooreds]

Offload user management

I am building a single app (web, mobile) and want a mature, bullet proof user management system that I don't have to build but can integrate easily. Auth doesn't provide any differentiation, so I want something that I can set and forget.

[mooreds]

Proxy integration

Plug the auth system into a proxy such as nginx or apache. The proxy communicates with fusionauth, fusionauth authorizes or disallows access. Arbitrary URLs are protected. See also this post and https://fusionauth.io/community/forum/topic/2264/securing-docker

[mooreds]

Web agency

Design and development companies often need to quickly deliver beautiful sites. Auth is required, but not a real value add. Getting up to speed on one auth system means it can be used across many different projects, especially if it integrates well with multiple platforms and can be themed.

[mooreds]

Subscription management

You have an application with protected resources which you want to allow or disallow access to. Using roles and user actions, you can prevent access or even signin for users.

[mooreds]

Social/SAML/OIDC Integration Layer

You've built out your own auth system but now need to add social sign-on and integration with a variety of SAML and OIDC providers. You're maintaining auth records in your own system, but may want to migrate in the future. But right now you need the ability to easily add additional identity providers for your users.

[mooreds]

Handle authentication alone

Use FusionAuth to handle the initial authentication, perhaps using social sign-ons or federation, but then push the user id to your database and have your database handle everything else (authorization, user management, etc)

[mooreds]

Third party verification

• client does client credentials grant against your IdP and gets a token A back
• client presents token A to 3rd party API
• 3rd party API returns token B to client
• client presents token B to other 3rd party APIs

Token A (jwt token usually, sometimes with some special configuration depending on 3rd party) has the claims specified by the specification of 3rd Party API. We configured it accordingly. Usually 3rd party would verify the signature as well... Token B is the access token for 3rd party APIs, supposedly configured to pass the security check configured by api producer, whatever they are, opaque to us

[mooreds]

General app gateway

Place all apps behind a proxy. Have the proxy delegate authentication to FusionAuth. Set up apps to only accept connections from the proxy.

When a user attempts to access an app, the proxy sends them to FusionAuth. They authenticate and are then forwarded on to the application, perhaps with a header or other means of passing on the user info.

See https://news.ycombinator.com/item?id=29199044 for another take on this.

[mooreds]

Closing this as haven't have comments from the community in a few years and we'll be building out some use case examples in the docs shortly.