Trouble shooting & FAQ

Can I use the same SSO login code for multiple teams?

No, but there is a good reason for it and a work-around.

Reason: we could implement this, but that would require that we disable implicit user creation for those teams. Implicit user creation means that a person who has never logged onto wire before can use her credentials for the IdP to get access to wire, and create a new user based on those credentials. In order for this to work, the IdP must uniquely determine the team.

Work-around: on your IdP dashboard, you can set up a separate app for every wire team you own. Each IdP will get a different metadata file, and can be registered with its target team only. This way, users from different teams have different SSO logins, but the IdP operators can still use the same user base for all teams. This has the extra advantage that a user can be part of two teams with the same credentials, which would be impossible even with the hypothetical fix.

Can an existing user without IdP (or with a different IdP) be bound to a new IdP?

No. This is a feature we never fully implemented. Details / latest updates:

If you get an error when returning from your IdP


You have successfully authenticated on your IdP and are redirected into wire. Wire shows a white page with an error message that contains a lot of machine-readable info.

What we need from you:

  • Your SSO metadata file

  • The SSO login code (eg. wire-3f61d2ce-525c-11ea-b8da-cf641a7b716a; you can find it in the team settings where you registered your IdP)

  • The full browser page with the error message (copy it into your clipboard and insert it into an email to us, or save the page as an html file and send that to us)

With all this information, please get in touch with our customer support.

Do I need any firewall settings?


There is nothing to be done here. There is no internet traffic between your SAML IdP and the wire service. All communication happens via the browser or app.

Why does the team owner have to keep using password?

The user who creates the team cannot be authenticated via SSO. There is fundamentally no easy way around that: we need somebody to give us the IdP credentials, and we need to trust that somebody. For now, that’s the team owner with their password.

(It is also unwise to bind that owner to SAML once it’s installed. If there is ever any issue with SAML authentication that can only be resolved by updating the IdP metadata in team settings, the owner must still have a way to authenticate in order to do that.)

There is a good workaround, though: you can create a team with user A and use A for registering the IdP. All the users for everyday use and maintenance of the team, including admins and owners, can then be created via SSO (either IdP or SCIM). The original user A is only ever used for IdP registration and upgrade of IdP-authenticated owners / admins.

In practice, user A and some owner authenticated via IdP would then be controlled by the same person, probably.

What should the SAML response look like?

Here is an example that works. Much of this beyond the subject’s NameID is required by the SAML standard. If you can find a more minimal example that still works, we’d be love to take a look.

<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="..." IssueInstant="..." Version="2.0">
  <ds:Signature xmlns:ds="">
      <ds:CanonicalizationMethod Algorithm=""/>
      <ds:SignatureMethod Algorithm=""/>
      <ds:Reference URI="#...">
          <ds:Transform Algorithm=""/>
          <ds:Transform Algorithm="">
            <ec:InclusiveNamespaces xmlns:ec="" PrefixList="ds saml"/>
        <ds:DigestMethod Algorithm=""/>
    <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">...</saml:NameID>
    <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
      <saml:SubjectConfirmationData Address="..." InResponseTo="..." NotOnOrAfter="..."
  <saml:Conditions NotBefore="..." NotOnOrAfter="...">
  <saml:AuthnStatement AuthnInstant="..." SessionNotOnOrAfter="...">
    <saml:SubjectLocality Address="..."/>

Why does the auth response not contain a reference to an auth request? (Also: can i use IdP-initiated login?)

tl;dr: Wire only supports SP-initiated login, where the user selects the auth method from inside the app’s login screen. It does not support IdP-initiated login, where the user enters the app from a list of applications in the IdP UI.

The full story

SAML authentication can be initiated by the IdP (eg., Okta or Azure), or by the SP (Wire).

A user doing IdP-initiated authentication starts from some dashboard in her IdP portal, and selects a button or link to the SP she wants to interact with. The IdP will then refer the user to the SP with the SAML credentials in the redirect request. The user needs to do nothing but wait for the App to start.

In SP-initiated authentication, the user starts off on the login screen of the app or web site of the SP. She selects the IdP she wants to authenticate with, and gets redirected there with an authentication request.

That last part is important: the authentication request contains cryptographic credentials that make some attacks (like machine-in-the-middle attacks for stealing sessions and making users impersonate rogue accounts) hard that were otherwise quite feasible.

Wire therefore only supports SP-initiated login.