Skip to content

Authentication Methods

Introduction

Flywheel supports two primary authentication methods to allow users to access the platform securely. This article explains the authentication methods, available identity providers, and when to use each one.

Authentication Methods

Flywheel provides two distinct authentication methods:

Web Session Authentication

Web Session authentication allows users to sign in through the Flywheel web interface using their credentials from supported identity providers. When a user successfully authenticates, Flywheel creates a web session that remains active until one of the following occurs:

  • User logs out
  • Session inactivity timeout
  • Identity provider enforced expiration

When to use:

  • For interactive access through the Flywheel web interface
  • For users who need to browse, search, and manage data through the UI
  • For administrative tasks performed through the web interface

API Key Authentication

API keys provide programmatic access to Flywheel without interactive login. They are used by scripts, applications, and command-line tools to authenticate directly with the Flywheel API.

When to use:

  • For automated scripts and workflows
  • For CLI tool authentication
  • For application integrations
  • For programmatic data access and transfers

How to configure: See Create API Keys

Learn more about API key concepts.

Identity Providers for Web Session Authentication

Web Session authentication supports multiple identity providers. The Flywheel customer (your organization) determines which identity providers are enabled for your specific Flywheel instance.

Private Institutional Providers

Private institutions can integrate their own identity management systems with Flywheel through Auth0. Flywheel supports the following protocols for private institutional authentication:

  • OIDC (OpenID Connect)
  • SAML (Security Assertion Markup Language)
  • Azure Entra ID (formerly Azure Active Directory)

This enables users to sign in using their institutional credentials with seamless single sign-on.

Typical use case: Private organizations with existing identity management infrastructure

Configuration: Contact your Flywheel administrator or Flywheel support to configure private institutional authentication.

Public Institutional Providers

Public research institutions and organizations can provide authentication for their users through CILogon. CILogon enables users to sign in using their institutional credentials from participating organizations.

Supported through: CILogon

Typical use case: Academic institutions, multi-institutional collaborations, and research consortia

How to configure: See Add Institutional Collaborators

Social Identity Providers

Flywheel supports social identity providers for users without institutional credentials.

ORCID

ORCID (Open Researcher and Contributor ID) provides a persistent digital identifier for researchers. Flywheel uses the primary email address associated with an ORCID account for authentication.

When to use:

  • For researchers who already have ORCID accounts
  • For international collaborations where institutional authentication may not be feasible
  • When you want to leverage existing researcher identity infrastructure

How to configure: See Configure ORCID Authentication

Google

Google accounts can be used for authentication when enabled by your Flywheel administrator.

When to use:

  • For users with Google accounts
  • For quick onboarding of collaborators
  • When institutional authentication is not available

Identity Provider Configuration

The available identity providers for your Flywheel instance are configured by your organization's Flywheel administrator. Not all identity providers may be available for your specific instance. Contact your Flywheel administrator to enable additional identity providers.

Authentication Flow

Web Session Authentication Flow

  1. User navigates to the Flywheel web interface
  2. User selects an identity provider (ORCID, institutional login, Google, etc.)
  3. Identity provider verifies the user's credentials
  4. Flywheel creates a web session for the authenticated user
  5. Flywheel grants access based on the user's assigned roles and permissions

API Key Authentication Flow

  1. Application or script makes an API request with an API key
  2. Flywheel validates the API key
  3. Flywheel grants access based on the permissions associated with the API key

Email Address Requirements

All authentication methods in Flywheel require a unique email address:

  • ORCID: Uses the primary email address from the ORCID profile
  • CILogon: Uses the eduPersonPrincipalName (ePPN) which typically looks like an email address
  • Direct accounts: Uses the email address specified when creating the user

Case Sensitivity

Email addresses in Flywheel are case-sensitive. Ensure consistency when creating users and configuring authentication.

Troubleshooting

If users experience authentication issues, see Troubleshooting Authentication.