OpenID Connect (OIDC)

Introduction

OpenID Connect is an open standard for single sign-on, identity and access management. With Myota Vault it can be used for user authentication and client authorization against an external identity provider(IdP).

Benefits of using Myota Vault with OpenID Connect

  • Increased security by shifting user authentication to an external identity provider.

  • Seamless integration into single sign-on (SSO) environments as well as with third party products.

  • Centralized client management within the identity provider.

  • Enterprise-grade security through the use of authentication security features (e.g., multi-factor authentication) and policies (e.g., automatic token expiration on certain conditions) provided by identity providers.

Myota Vault only supports one configured identity provider which is then valid for all requests.

Click on the OAuth code flow sequence diagram link to get more details on the flow sequence.

Supported Identity Providers

Myota Vault can work with identity providers (IdP) that support OpenID Connect. There are many identity providers available and the OpenID Connect implementations vary a lot in terms of supported features as well as configuration needs.

The currently supported products are

(1) …​ Note that ADFS does not support client-secrets that contain an _ (underscore).

Please get in touch with Myota Vault Consulting if you need help with a specific identity provider product.

Prerequisites

Setting up Myota Vault to work with OpenID Connect requires a couple of components to work together:

  • An external identity provider configured to work with the Myota Vault components

  • A distributed memcache setup - such as Redis or Memcached - is required to operate this app. Follow the caching documentation on how to set it up.

  • The OpenID Connect app enabled on Myota Vault.

  • Set the environment variable:

    MYOTA_HTTP_COOKIE_SAMESITE=None

    See config.sample.php and Schemeful Same-Site for examples and details.

  • Settings for the OpenID Connect App

    See config.apps.sample.php for examples and details or see section Save Settings in the Database below when running clustered setups.

  • Service discovery for the Myota Vault Desktop and Mobile Apps

Set Up Service Discovery

  1. Webserver Service Discovery Information

    In order to allow the Myota Vault Clients (Desktop/Android/iOS) to make use of OpenID Connect, the webserver serving Myota Vault needs to provide service discovery information under the following static path:

    https://cloud.example.com/.well-known/openid-configuration

  2. App Service Discovery Information

    When enabled, the OpenID Connect App provides the service discovery information on the endpoint:

    https://cloud.example.com/index.php/apps/openidconnect/config

  3. Webserver Rewrite Rule

    To make the endpoint available under the static service discovery path, it is recommended to set the following environment variable:

    This variable sets the following rule in the embedded .htaccess file on container startup:

    RewriteRule ^/.well-known/openid-configuration /index.php/apps/openidconnect/config

  4. Once service discovery is available as described above, the Myota Vault clients will attempt to connect via OpenID Connect.

General Example Setup

All IdPs have their own setup, but often share common ways of configuring things. Although not identical, the Kopano Konnect example may be a good starting point for the specific configuration of your setup. As Microsoft with Azure AD is different, it has its own example section.

Example Setup Using Kopano Konnect

Follow this link to see Example Setup Using Kopano Konnect.

Example Setup Using Microsoft Azure AD

Follow this link to see Example Setup Using Microsoft Azure AD.

Example Setup Using OneLogin

Follow this link to see Example Setup Using OneLogin.

Myota Vault Desktop and Mobile Apps

Myota Vault Desktop and Mobile Apps detect whether OIDC is available (service discovery) and use this login method when a new account is created.

The Desktop and Mobile apps have a default client ID and secret hard-coded, which are used for Myota Vault’s oauth2 app. When using Kopano as IdP, it does not pre-define a client ID and secret. You can use the default ones of the client to configure Kopano properly. With some IdPs like MS-Azure, these and other required parameters come from the IdP and must be coded into the client. Note that each IdP has different requirements. Get in touch with Myota Vault for a branding subscription to customize the clients according to your needs.

Client IDs, Secrets and Redirect URIs

All IdPs can use Myota Vault’s default client IDs, secrets and redirect URIs with the exception of Microsoft Azure AD, which uses a different approach. Here is the data necessary for the configuration.

Client ID

Source Key

Server/Web

as specified via environment variables

Desktop

xdXOt13JKxym1B1QcEncf2XDkLAexMBFwiT9j6EfhhHFJhs2KM9jbjTmf8JBXE69

Android

e4rAsNUSIUs0lF4nbv9FmCeUkTlV9GdgTLDH1b5uie7syb90SzEVrbN7HIpmWJeD

iOS

mxd5OQDk6es5LzOzRvidJNfXLUZS2oN3oUFeXPP8LpPrhx3UroJFduGEYIBOxkY1

Client Secret

Source Key

Server/Web

as specified via environment variables

Desktop

UBntmLjC2yYCeHwsyj73Uwo9TAaecAetRwMw0xYcvNL9yRdLSUi0hUAHfvCHFeFh

Android

dInFYGV33xKzhbRmpqQltYNdfLdJIfJ9L5ISoKhNoT9qZftpdWSP71VrpGR9pmoD

iOS

KFeFWWEZO9TkisIQzR3fo7hfiMXlOpaqP8CFuTbSHzV1TUuGECglPxpiVKJfOXIx

Redirect URIs

Source Redirect URI 1

Desktop ≤ 2.8

http://localhost

Desktop ≥ 2.9

http://127.0.0.1

Android

oc://android.myota.io

iOS

oc://ios.myota.io

(1) See the following note when using Microsoft Azure AD and 127.0.0.1 as redirect URI.

Default Scope and Prompt Parameters

Myota Vault desktop and mobile apps come with default scope and prompt parameters. These parameters can be modified in custom branded builds. See the OIDC Authentication Request specs for more details about the parameters.

Parameter Default value

scope

openid offline_access email profile

prompt

select_account consent
(for Android you need app version 4.0+)

Migrate Clients from Basic Authentication to OIDC

If your users are logged in to their desktop and mobile clients via basic authentication (username/password) against Myota Vault and you are not using OAuth2 to authorize the Myota Vault clients, a migration to OIDC can be conducted as follows:

  1. Make sure you have a working OIDC configuration based on the above sections.

  2. Enable the OpenID Connect App.

  3. Enable token-only authentication.

Once the OpenID Connect App is enabled, token-only authentication is enforced and service discovery is properly set up, the Myota Vault clients will ask the users to re-authenticate. After a successful re-authentication, the migration is done.

To connect legacy clients, users have to generate special app passwords (tokens).

Migrate Clients from OAuth2 to OIDC

If you use OAuth2 for client authorization, a migration to OIDC can be conducted as follows:

  1. Make sure you have a working configuration based on the above sections.

  2. Enable the OpenID Connect App (while having the OAuth2 App still enabled).

  3. Disable the OAuth2 App.

Once the OAuth2 App is disabled and service discovery is properly set up, the Myota Vault Clients will ask the users to re-authenticate. After a successful re-authentication, the migration is done.

Migrate Web Login (and Client Login) from SAML to OIDC

If you are using SAML/SSO, a migration to OIDC depends on your identity provider and is not straight forward. Please get in touch with Myota Vault Consulting to plan the migration.