Authentication Through Microsoft

Overview

One of the login options for dex uses the Microsoft OAuth2 flow to identify the end user through their Microsoft account.

When a client redeems a refresh token through dex, dex will re-query Microsoft to update user information in the ID Token. To do this, dex stores a readonly Microsoft access and refresh tokens in its backing datastore. Users that reject dex’s access through Microsoft will also revoke all dex clients which authenticated them through Microsoft.

Caveats

groups claim in dex is only supported when tenant is specified in Microsoft connector config. In order for dex to be able to list groups on behalf of logged in user, an explicit organization administrator consent is required. To obtain the consent do the following:

  • when registering dex application on https://apps.dev.microsoft.com add an explicit Directory.Read.All permission to the list of Delegated Permissions
  • open the following link in your browser and log in under organization administrator account:

https://login.microsoftonline.com/<tenant>/adminconsent?client_id=<dex client id>

Configuration

Register a new application on https://apps.dev.microsoft.com via Add an app ensuring the callback URL is (dex issuer)/callback. For example if dex is listening at the non-root path https://auth.example.com/dex the callback would be https://auth.example.com/dex/callback.

The following is an example of a configuration for examples/config-dev.yaml:

  1. connectors:
  2.   - type: microsoft
  3.     # Required field for connector id.
  4.     id: microsoft
  5.     # Required field for connector name.
  6.     name: Microsoft
  7.     config:
  8.       # Credentials can be string literals or pulled from the environment.
  9.       clientID: $MICROSOFT_APPLICATION_ID
  10.       clientSecret: $MICROSOFT_CLIENT_SECRET
  11.       redirectURI: http://127.0.0.1:5556/dex/callback

tenant configuration parameter controls what kinds of accounts may be authenticated in dex. By default, all types of Microsoft accounts (consumers and organizations) can authenticate in dex via Microsoft. To change this, set the tenant parameter to one of the following:

  • common- both personal and business/school accounts can authenticate in dex via Microsoft (default)
  • consumers - only personal accounts can authenticate in dex
  • organizations - only business/school accounts can authenticate in dex
  • <tenant uuid> or <tenant name> - only accounts belonging to specific tenant identified by either <tenant uuid> or <tenant name> can authenticate in dex

For example, the following snippet configures dex to only allow business/school accounts:

  1. connectors:
  2.   - type: microsoft
  3.     # Required field for connector id.
  4.     id: microsoft
  5.     # Required field for connector name.
  6.     name: Microsoft
  7.     config:
  8.       # Credentials can be string literals or pulled from the environment.
  9.       clientID: $MICROSOFT_APPLICATION_ID
  10.       clientSecret: $MICROSOFT_CLIENT_SECRET
  11.       redirectURI: http://127.0.0.1:5556/dex/callback
  12.       tenant: organizations

Groups

When the groups claim is present in a request to dex and tenant is configured, dex will query Microsoft API to obtain a list of groups the user is a member of. onlySecurityGroups configuration option restricts the list to include only security groups. By default all groups (security, Office 365, mailing lists) are included.

By default, dex resolve groups ids to groups names, to keep groups ids, you can specify the configuration option groupNameFormat: id.

It is possible to require a user to be a member of a particular group in order to be successfully authenticated in dex. For example, with the following configuration file only the users who are members of at least one of the listed groups will be able to successfully authenticate in dex:

  1. connectors:
  2.   - type: microsoft
  3.     # Required field for connector id.
  4.     id: microsoft
  5.     # Required field for connector name.
  6.     name: Microsoft
  7.     config:
  8.       # Credentials can be string literals or pulled from the environment.
  9.       clientID: $MICROSOFT_APPLICATION_ID
  10.       clientSecret: $MICROSOFT_CLIENT_SECRET
  11.       redirectURI: http://127.0.0.1:5556/dex/callback
  12.       tenant: myorg.onmicrosoft.com
  13.       groups:
  14.         - developers
  15.         - devops

Also, useGroupsAsWhitelist configuration option, can restrict the groups claims to include only the user’s groups that are in the configured groups.

You can use the emailToLowercase (boolean) configuration option to streamline UPNs (user email) from Active Directory before putting them into an id token. Without this option, it can be tough to match the email claim because a client application doesn’t know whether an email address has been added with capital- or lowercase letters. For example, it is hard to bind Roles in Kubernetes using email as a user name (–oidc-username-claim=email flag) because user names are case sensitive.

  1. connectors:
  2.   - type: microsoft
  3.     # Required field for connector id.
  4.     id: microsoft
  5.     # Required field for connector name.
  6.     name: Microsoft
  7.     config:
  8.       # Credentials can be string literals or pulled from the environment.
  9.       clientID: $MICROSOFT_APPLICATION_ID
  10.       clientSecret: $MICROSOFT_CLIENT_SECRET
  11.       redirectURI: http://127.0.0.1:5556/dex/callback
  12.       tenant: myorg.onmicrosoft.com
  13.       groups:
  14.         - developers
  15.         - devops
  16.       # All relevant E-Mail Adresses delivered by AD will transformed to
  17.       # lowercase if config is TRUE
  18.       emailToLowercase: true