dex Documentation

File: README.md Copy Chapter

dex - A federated OpenID Connect provider

Dex is an identity service that uses OpenID Connect to drive authentication for other apps.

Dex acts as a portal to other identity providers through "connectors." This lets dex defer authentication to LDAP servers, SAML providers, or established identity providers like GitHub, Google, and Active Directory. Clients write their authentication logic once to talk to dex, then dex handles the protocols for a given backend.

ID Tokens Copy Chapter

ID Tokens are an OAuth2 extension introduced by OpenID Connect and dex's primary feature. ID Tokens are JSON Web Tokens (JWTs) signed by dex and returned as part of the OAuth2 response that attests to the end user's identity. An example JWT might look like:

eyJhbGciOiJSUzI1NiIsImtpZCI6IjlkNDQ3NDFmNzczYjkzOGNmNjVkZDMyNjY4NWI4NjE4MGMzMjRkOTkifQ.eyJpc3MiOiJodHRwOi8vMTI3LjAuMC4xOjU1NTYvZGV4Iiwic3ViIjoiQ2djeU16UXlOelE1RWdabmFYUm9kV0kiLCJhdWQiOiJleGFtcGxlLWFwcCIsImV4cCI6MTQ5Mjg4MjA0MiwiaWF0IjoxNDkyNzk1NjQyLCJhdF9oYXNoIjoiYmk5NmdPWFpTaHZsV1l0YWw5RXFpdyIsImVtYWlsIjoiZXJpYy5jaGlhbmdAY29yZW9zLmNvbSIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJncm91cHMiOlsiYWRtaW5zIiwiZGV2ZWxvcGVycyJdLCJuYW1lIjoiRXJpYyBDaGlhbmcifQ.OhROPq_0eP-zsQRjg87KZ4wGkjiQGnTi5QuG877AdJDb3R2ZCOk2Vkf5SdP8cPyb3VMqL32G4hLDayniiv8f1_ZXAde0sKrayfQ10XAXFgZl_P1yilkLdknxn6nbhDRVllpWcB12ki9vmAxklAr0B1C4kr5nI3-BZLrFcUR5sQbxwJj4oW1OuG6jJCNGHXGNTBTNEaM28eD-9nhfBeuBTzzO7BKwPsojjj4C9ogU4JQhGvm_l4yfVi0boSx8c0FX3JsiB0yLa1ZdJVWVl9m90XmbWRSD85pNDQHcWZP9hR6CMgbvGkZsgjG32qeRwUL_eNkNowSBNWLrGNPoON1gMg

ID Tokens contains standard claims assert which client app logged the user in, when the token expires, and the identity of the user.

{
  "iss": "http://127.0.0.1:5556/dex",
  "sub": "CgcyMzQyNzQ5EgZnaXRodWI",
  "aud": "example-app",
  "exp": 1492882042,
  "iat": 1492795642,
  "at_hash": "bi96gOXZShvlWYtal9Eqiw",
  "email": "[email protected]",
  "email_verified": true,
  "groups": [
    "admins",
    "developers"
  ],
  "name": "Jane Doe"
}

Because these tokens are signed by dex and contain standard-based claims other services can consume them as service-to-service credentials. Systems that can already consume OpenID Connect ID Tokens issued by dex include:

• Kubernetes
• AWS STS

For details on how to request or validate an ID Token, see "Writing apps that use dex".

Kubernetes and Dex Copy Chapter

Dex runs natively on top of any Kubernetes cluster using Custom Resource Definitions and can drive API server authentication through the OpenID Connect plugin. Clients, such as kubelogin and kubectl, can act on behalf of users who can login to the cluster through any identity provider dex supports.

• More docs for running dex as a Kubernetes authenticator can be found here.
• You can find more about companies and projects which use dex, here.

Connectors Copy Chapter

When a user logs in through dex, the user's identity is usually stored in another user-management system: a LDAP directory, a GitHub org, etc. Dex acts as a shim between a client app and the upstream identity provider. The client only needs to understand OpenID Connect to query dex, while dex implements an array of protocols for querying other user-management systems.

A "connector" is a strategy used by dex for authenticating a user against another identity provider. Dex implements connectors that target specific platforms such as GitHub, LinkedIn, and Microsoft as well as established protocols like LDAP and SAML.

Depending on the connectors limitations in protocols can prevent dex from issuing refresh tokens or returning group membership claims. For example, because SAML doesn't provide a non-interactive way to refresh assertions, if a user logs in through the SAML connector dex won't issue a refresh token to its client. Refresh token support is required for clients that require offline access, such as kubectl.

Dex implements the following connectors:

Stable, beta, and alpha are defined as:

• Stable: well tested, in active use, and will not change in backward incompatible ways.
• Beta: tested and unlikely to change in backward incompatible ways.
• Alpha: may be untested by core maintainers and is subject to change in backward incompatible ways.

All changes or deprecations of connector features will be announced in the release notes.

Documentation Copy Chapter

See the official documentation for getting started, configuration, and usage guides.

Reporting a vulnerability Copy Chapter

Please see our security policy for details about reporting vulnerabilities.

Getting help Copy Chapter

• For feature requests and bugs, file an issue.
• For general discussion about both using and developing Dex:
  • join the #dexidp on the CNCF Slack
  • open a new discussion

Contributing Copy Chapter

Please see CONTRIBUTING.md for development setup, guidelines, and how to submit pull requests.

License Copy Chapter

The project is licensed under the Apache License, Version 2.0.

File: docs/enhancements/README.md Copy Chapter

Dex Enhancement Proposal

Why do we need it? Copy Chapter

Dex Enhancement Proposal (DEP) is a design document providing information to the community, or describing a new feature for Dex.

We intend DEPs to be the primary mechanisms for proposing major new features or significant changes to existing ones.
This will make it easier for the community to describe, track, and look through the history of changes that affected the development of the project.

Process Copy Chapter

Before starting Copy Section

1. Search GitHub for previous issues, discussions and DEPs.
2. If a discussion does not exist, open it.
3. Ensure that writing enhancement proposal is necessary for you change by discussing it with a community.

Writing an enhancement proposal Copy Section

1. Fork the repo.
2. Copy the docs/enhancements/_title-YYYY-MM-DD-#issue.md template with the appropriate
   name.
3. Fill all sections according to hints in them. Provide as much information as you can.
4. Submit your PR and discuss it with the Dex team.

File: docs/README.md Copy Chapter

These documents have moved to the dexidp/website repo.

File: examples/grpc-client/README.md Copy Chapter

Running a Dex gRPC client

Using gRPC, a client application can directly call methods on a server application as if it was a local object. The schema for Dex's gRPC API calls is defined in api/api.proto. client.go is an example client program that makes a bunch of API calls to the dex server. For further details on the Dex API refer the [documentation][https://dexidp.io/docs/api/].

Generating Credentials Copy Chapter

Before running the client or the server, TLS credentials have to be setup for secure communication. Run the cred-gen script to create TLS credentials for running this example. This script generates a ca.crt, server.crt, server.key, client.crt, and client.key.

# Used to set certificate subject alt names.
export SAN=IP.1:127.0.0.1

# Run the script
./examples/grpc-client/cert-gen

To verify that the server and client certificates were signed by the CA, run the following commands:

openssl verify -CAfile ca.crt server.crt
openssl verify -CAfile ca.crt client.crt

Running the Dex server Copy Chapter

To expose the gRPC service, the gRPC option must be enabled via the dex config file as shown below.

# Enables the gRPC API.
grpc:
  addr: 127.0.0.1:5557
  tlsCert: server.crt
  tlsKey: server.key

Start an instance of the dex server with an in-memory data store:

./bin/dex serve examples/grpc-client/config.yaml

Running the Dex client Copy Chapter

Finally run the Dex client providing the CA certificate, client certificate and client key as arguments.

./bin/grpc-client -ca-crt=ca.crt -client-crt=client.crt -client-key=client.key

Running the gRPC client will cause the following API calls to be made to the server

1. CreatePassword
2. ListPasswords
3. VerifyPassword
4. DeletePassword
5. CreateClient
6. ListClients
7. DeleteClient

Cleaning up Copy Chapter

Run the following command to destroy all the credentials files that were created by the cert-gen script:

./examples/grpc-client/cert-destroy

File: pkg/httpclient/readme.md Copy Chapter

Regenerate testdata

server.csr.cnf Copy Section

[req]
default_bits = 2048
prompt = no
default_md = sha256
distinguished_name = dn

[dn]
C=US
ST=RandomState
L=RandomCity
O=RandomOrganization
OU=RandomOrganizationUnit
[email protected]
CN = localhost

and

v3.ext Copy Section

authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = localhost
IP.1 = 127.0.0.1

Then enter the following commands: Copy Section

openssl genrsa -out rootCA.key 2048

openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 3650 -out rootCA.pem -config server.csr.cnf

openssl req -new -sha256 -nodes -out server.csr -newkey rsa:2048 -keyout server.key -config server.csr.cnf

openssl x509 -req -in server.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out server.crt -days 3650 -sha256 -extfile v3.ext