Use Cases for Federated Single Sign On

OpenWebAuth is a federated remote authentication protocol. It is light weight so that it can be used in a variety of projects and applications, including social media, blogs, forums, content websites, and more. You can choose to be an identity provider or a destination server, or both.

Login with Social Web Account

Instead of forcing every user to create a local account, you can allow them to sign on with their OpenWebAuth-compatible account. And if you prefer to not manage local accounts at all, you can force all users to sign on with a remote social web account.

Verification of Control of Social Web Account

If you allow a user on your website or platform to associate a social web account with their user profile, you can use OpenWebAuth to verify that they control the social web account they claim their control.

Seamless Single Sign On for Multiple Domains

If you operate sites on more than one domain name, you can provide a way for people to sign into them all with the same social web account, rather than having multiple local accounts. Since you can pass the username via a URL, they will be automatically logged into the other domain (if the user allows this), which makes moving between domains seamless.

Even if the user does not allow automatic logins by passing a URL parameter, they can remotely authenticate with just their username; no password required. As long as they are currently logged into their home server, it will authenticate them.

Verified Comments on Blogs, Forums, and Non-Federated Communities

If you have a website that allows comments, you can use OpenWebAuth to authenticate the user. You can then associate their comments with their social web account. This gives you more control over comments, since you can block users, add them to an allowlist, or require moderation of comments from first time commenters.

Grant Access to Restricted Resources and Content

If your website or platform has a permission system that controls access to resources, you can grant access to users who do not have a local account. Any permissions that you grant to a local user can be granted to a remote social web user, if desired.

For example, if you have courses, articles, or other content that you only want certain users to see, you can require that a user authenticate with either a local account or a remote social web account via OpenWebAuth. You can even grant specific users the ability to edit or modify certain resources, such as wikis or articles.

Even if you do not have private resources yourself, if you want your users to have access to resources on other websites and platforms, you can be an identity provider, which allows them to log into other servers.

Operate Only as an Identity Provider

You can issue social web identities to your users, allowing them to sign onto other servers using federated single sign on.

Since OpenWebAuth is an authentication protocol, and not a authorization protocol, you are not granting the remote server any privileges on your server. You simply provide a user identity that can be used for federated single sign on.

Since this is the case, you can issue identities without worrying about what a remote server might do to your server.

Separating Official Accounts from User Accounts

If you have official accounts and also allow users to create local accounts, you may not want them on the same domain or subdomain, in order to differentiate between the two. You can place users on their own domain or subdomain, yet allow them to log into the main domain using OpenWebAuth, creating a seamless experience.

For example, official accounts might be located on example.com but your users might be located on example.social. With OpenWebAuth, the example.social users would be able to log into example.com to access resources requiring authentication.

Two Factor Authentication (2FA)

You can use OpenWebAuth as a second or even third form of authentication. Since OpenWebAuth can work in the background, you can silently verify that they are currently logged into their home server on the same device (if the user allows this).

CAPTCHA Alternative or Supplement

Although OpenWebAuth is not a Turing test, it does verify that the visitor is currently logged into their home server on the same device. This does not verify that the user is a person or a bot, but if they choose to authenticate, then their identity would be associated with a particular user and a particular domain name. You can then use this information, in addition to CAPTCHA, webfinger, allowlists, blocklists, and other methods to help distinguish between people and bots.