Shibboleth Protocol Options

Shibboleth uses either Security Assertion Markup Language (SAML) or OpenID Connect (OIDC), two industry standard protocols, to share the attributes (SAML) or claims (OIDC). This means you can set it up to work with a wide variety of vendor-provided software and services. There are a few key differences between SAML and OIDC.

Setup Options for Shibboleth—SAML or OIDC

Technology stack diagram showing how Shibboleth identity provider interacts with OIDC and SAML


Shibboleth with SAML enables you to do the following:

  • Restrict access only to people who should have access based on authoritative information about their relationship(s) to the university.
  • Allow people from other institutions that are a part of the InCommon Federation or eduGAIN federation to log in using their institutional credentials.
  • Personalize the user experience of your application according to user affiliation.
  • Protect information on a server by requiring a person to be authenticated to gain access. Shibboleth can be used to protect all the information on a server or only specific resources on the server.


Some services require OIDC specifically and do not work with SAML. There are also web extensions for installing OIDC that may be simpler to implement than SAML. Here are some aspects of OIDC:

  • Ease of configuration. The configuration process is simpler for OIDC than that for SAML.
  • Mobile application friendly.
  • Only allows you to authenticate persons with U-M credentials. OIDC does not yet support a federated access model.
  • Service Providers using OIDC are currently not able to require two-factor. Two-factor will be enforced if an individual is opted-in to use two-factor.
  • Note: When offline, users are prompted to consent with each login.
  • U-M supports a subset of the standard OIDC claims (attributes):
    • Name and parts of name
    • uniqname
    • Email address

See also: