On this page you can find help for all actions you can do on orpheus.

The service OrPhEUS or the OIDC ProvidEr featUre Support portal is a system to compare different OpenID Connect providers, check which functionality is supported by these, and investigate how certain OpenID Connect flows work.

The two main aspects covered by orpheus are:

Comparing Different Providers

Orpheus can be used to compare different OpenID Connect providers and check which functionality is supported by each of the providers. It can also be seen as a universal and extensible test suite for OpenID Connect providers. Orpheus does not only give information about a provider that is available from the provider's configuration endpoint, but with the help of the community orpheus is also capable of testing other features. So orpheus can answer questions such as:

  • Is the authorization code flow correctly working?
  • Is Token Revocation support and if only for refresh tokens or also for access tokens?
  • Is the access token a JWT?
  • Does the provider correctly sign ID tokens?

So orpheus can also be used to find discrepancies between what a provider says it supports and what it actually supports.

The comparison view gives a list with many different features and if / how these features are supported by each provider. The list is extensible and we like to hear you ideas. Requests can be send to
The comparison view has filters for searching for specific features and filtering the values for each provider. It is also possible to collapse categorized features.
You can also define your own comparison view with only the features you need with the exact ordering and grouping you want.

Investigating Flows

Orpheus can also be used to investigate some OpenID Connect flows. This might be useful

  • to get a first impression how a specific flow generally works,
  • to test if a certain flow is correctly working with a specific provider,
  • to give an example of how a specific flow can be done with a specific provider (the communication details are given so one can see data is exchanged during the communication),
  • to get an idea what information is avialable for this provider at which source (ID token, userinfo endpoint, JWT Access Token)

The information about a performed flow can also be shared with others for a limited amount of time, so it can also be used to help with debugging OIDC related problems.

  • Dynamic Features
    Currently available 25

    These are features or properties that can be tested dynamically. Orpheus will test these features regularly for all providers. The time when properties were checked the last time for a provider is given at the bottom of the comparison table.

    An example would be to check if the Registration Endpoint is advertised in the provider's openid configuration document.
  • Community Features
    Currently available 6

    These are features that cannot be checked automatically by orpheus alone, but it requires the help of the community. This category contains all features / properties that are related to tokens or if a certain flow is currently working correctly. Because such checks require user interaction, these can only be done with the help of the community.
    The values for these features will be updated everytime a user performs a flow where that feature can be checked.
    For all of the providers each of these features has its one timestamp indicating when it was checked the last time for this provider. If you feel that this time was too long ago, just perform the relevant flow and the value will be updated.

    An example would be to check if the Authorization Code Flow is correctly working or if the access token is a JWT.
  • Manual Features
    Currently available 5

    These are properties that neither can be checked fully-automatically nor semi-automatically with the help of the community, but only manually. These properties do not have a time associated when they were checked the last time. We try to keep this properties up to date. However, because these features require manual testing, it is always possible that a value might get outdated. If you notice that a value is outdated, please contact us at

    An example would be the information whether there is a web interface for registering clients.

At the following links you can find information about all available features. This information should help you understand what a particular feature is testing and which values are possible.

Currently the following OpenID Connect flows are implemented:

Authorization Code Flow
The authorization code flow is the standard web flow and can be started via the navigation bar.
Device Code Flow
The device code flow is a flow for browserless and input constraint devices (of course it can also be tested on other devices). It can be started via the navigation bar (not all providers support this flow).
Refresh Flow
The refresh flow uses a refresh token to obtain additional access tokens. It cannot be triggered directly, but it automatically runs when a orpheus obtains a refresh token through another flow.
Revocation Flow
The revocation flow is used to revocate a token. This flow cannot be triggered directly, but it automatically runs after orpheus obtained a token through another flow.