Manual setup

Federated identity requires the SMALL plan or above.

The feature previously known as Single sign-on (SSO) has been renamed to Federated identity (FedID) to better reflect the nature of the feature.

Federated identity manages user data across multiple networks and denotes where the credentials are stored. Your "federal" system becomes an "identity provider." When a user logs into your website, instead of providing credentials to Muut, we trust the "identity provider" to validate those credentials. So the user never has to log in with Muut, and never manually has to provide their information. That process is completely transparent to the user, so if they are logged into your site, they can post in the Muut forum—no separate login whatsoever.

You could, for example, tie your WordPress user accounts into Muut. It would then allow users to login and signup with your own WordPress authentication system. Once logged in, they'll be able to use Muut commenting and forums without having to create or login to an account through Muut.

This creates a seamless integration between your own website's user authentication and your Muut community solution.

If you’re using the WordPress or Shopify plugins Federated ID is built into the plugin, so no worries about building a backend solution. Some thirdparty plugins like MemberSpace for SquareSpace also support FedID. Otherwise, Federated ID requires some server side work.

User objects

There are one required and four optional parameters you’ll pass when denoting users with Federated ID:

  • id identifies the user—this should be the way that your website uniquely identifies the user, like the username or id number. Required
  • displayname is the full name. Required
  • email is the user’s email address (optional, for post notifications)
  • avatar is an absolute URL to the user’s profile image (optional)
  • is_admin where true gives administrative rights. (optional)

Once those are assigned, you pass that user object into the message before it gets encoded and signed; if those values are good to go, the user is authenticated and can post to the forum.

If a user is not currently logged into your website, you should pass an empty user object { user: {} } into the message.

Administrators and Moderators

The only method to assign administrators using Federated ID is to use the is_admin user object. If you assign an administrator using your Muut settings page, it'll automatically be overridden when they login and view the page.

However, we left the moderator object out specifically to allow you to add moderators via the settings page or user profile page. If you're not in a position to tag users with the is_admin object you can allow a user manage posts by them by making them a moderator.

Signed embed code

Federated ID requires extending the standard signed embed code to include the user data on the server side as well as the sso: true configuration variable on the client side embed.

<script src="//"></script>
<link rel="stylesheet" href="//">
<script src="//"></script>
<a id="my-community" href="">Community</a>

  sso: true,
  api: {
    // API key for "YOUR_COMMUNITY_NAME"- community
    key: 'YOUR_API_KEY',

    // generate following on the server side (see below)
    message: 'MESSAGE',
    signature: 'SIGNATURE',
    timestamp: TIMESTAMP

Click below to find your custom signed embedding code as well as your custom server side secure embedding code. Configure secure embedding

Note the small edit to your signed embed code adding sso: true.

On above code the MESSAGE, SIGNATURE and TIMESTAMP must be generated on the server side

You can also pass a login_url property into the configuration. The login_url will be where the user is directed, rather than the Muut Account popup, when they click on a post or reply text field, or the “Log In” link at the top of the embed. It is automatically appended with the Muut client path hash to open the proper location in the forum after login. So, the client configuration object would look something like:

var conf = {
    login_url: '',
    api: {
        key: 'yourApiKey',
        message: 'signedEmbedMessage',
        signature: 'signedEmbedSignature',
        timestamp: signedEmbedTimestamp


Please choose the programming language of your choice to generate the above variables:

// give us the user data
$user = array(
  'user' => array(
    "id" => "johndoe",
    "displayname" => "John Doe",
    "email" => "",
    "avatar" => "//",
    "is_admin" => true,

$message = base64_encode(json_encode($user()));
$timestamp = time();
$signature = sha1('YOUR_SECRET_KEY' . ' ' . $message . ' ' . $timestamp);
// give us the user data
var user = {
  user: {
    id: 'johndoe', // required
    displayname: 'John Doe', // required
    email: '',
    avatar: '//',
    is_admin: true

function SHA1(str) {
  var sum = require('crypto').createHash('sha1')
  return sum.digest('hex')

function BASE64(str) {
  return (new Buffer(str)).toString('base64')

var message = BASE64(JSON.stringify(user)),
    timestamp = Math.round( / 1000),
    signature = SHA1('YOUR_SECRET_KEY' + ' ' + message + ' ' + timestamp)
# give us the user data
user = {
  "user": {
    "id": 'johndoe', # required
    "displayname": 'John Doe', # required
    "email": '',
    "avatar": '//',
    "is_admin": True

import base64
import hashlib
import json
import time

# Timestamp in seconds (Improves security)
timestamp = int(time.time())

# Message (base64 encoded string)
message = base64.b64encode(json.dumps(user))

# Signature (signed with private key)
signature = hashlib.sha1(
   "YOUR_SECRET_KEY" + " " + message + " " + str(timestamp)).hexdigest()
# give us the user data
user = {
  :user => {
    :id => 'johndoe', # required
    :displayname => 'John Doe', # required
    :email => '',
    :avatar => '//',
    :is_admin => true,

require 'digest/sha1'
require 'base64'
require 'json'

# timestamp (in seconds). Improves security.
timestamp =

# Message (base64 encoded string)
message = Base64.strict_encode64 user.to_json

# Signature (signed with private key)
signature = Digest::SHA1.hexdigest "YOUR_SECRET_KEY #{message} #{timestamp}"
C Sharp
// give us the user data
var user = new { user = new {
  id = "johndoe",
  email = "",
  displayname = "John Doe",
  avatar = "//",
  is_admin = true
            // timestamp
            double MillesecondsSinceEpoch = new TimeSpan(DateTime.Now.ToUniversalTime().Ticks - new DateTime(1970, 1, 1).Ticks).TotalMilliseconds;
            int timestamp = (int)(MillesecondsSinceEpoch / 1000);

            // message
            string messageJSON = new System.Web.Script.Serialization.JavaScriptSerializer().Serialize(user) ;
            byte[] messageBytes = System.Text.Encoding.ASCII.GetBytes(messageJSON);
            string message64 = Convert.ToBase64String(messageBytes);

            // signature
            string signature = string.Format("{0} {1} {2}", "YOUR_SECRET_KEY", message64, timestamp);
            byte[] signatureBytes = System.Text.Encoding.ASCII.GetBytes(signature);
            byte[] hashedSignature = new System.Security.Cryptography.SHA1CryptoServiceProvider().ComputeHash(s ignatureBytes);
            signature = BitConverter.ToString(hashedSignature).Replace("-", string.Empty);

You can see that it is an extension of the code for signed embeds. In this case we have added the user data to the message generation.

The client initialization documentation has details on using a configuration object to initialize the embed client. With the attached hash, if the user was visiting a specific path of the forum before clicking login, the URL the user is taken to might look like!/mycat:topic-id, where the hash represents the path the user was on in the forum.

You can also add url_escape: true configuration option to escape the login URL (URL encoded), so the above example would look like:


Here is an insecure demo that generates the values on the client-side with JavaScript. It is an example ONLY. As we warn on the signed embeds instructions, NEVER generate the Federatied Identities message and signature on the client-side. Always generate the values on the server. Your secret key should not be seen by anyone. If people get access to your secret key then they can sign any request and authenticate as anyone they want. Anyone could post as any user, administrator or otherwise.