diff --git a/Documentation/getting-started.md b/Documentation/getting-started.md index a7328312..dbd6ca7f 100644 --- a/Documentation/getting-started.md +++ b/Documentation/getting-started.md @@ -88,7 +88,8 @@ Note: the issuer URL MUST have an `https` scheme in production to meet spec comp The worker and overlord are up and running, but we need to tell dex what connectors we want to use to authenticate. For this case we'll set up a local connector, where dex manages credentials and provides a UI for authentication, and a Google OIDC connector. -If you prefer to use the Google OIDC Identity Provider (IdP), just omit the second entry in the JSON connector list. Note that you must replace DEX_GOOGLE_CLIENT_{ID,SECRET} with the client ID and client Secret you got when you registered your project with the Google developer console. +If you prefer to use the Google OIDC Identity Provider (IdP), just omit the second entry in the JSON connector list. Note that you must replace `DEX_GOOGLE_CLIENT_SECRET` and `DEX_GOOGLE_CLIENT_ID` with the client secret and client ID you got when you registered your project with the Google developer console. + ``` cat << EOF > /tmp/dex_connectors.json [ @@ -116,6 +117,7 @@ One thing to note here that's a bit confusing here is that in the case of the Go Like all OAuth2/OIDC IdPs, clients must be registered with the IdP (dex), along with their valid redirect URLS. New clients can be registered with the dexctl CLI tool: + ``` eval "$(./bin/dexctl -db-url=$DEX_DB_URL new-client http://127.0.0.1:5555/callback)" ``` diff --git a/README.md b/README.md index 409a49b4..c371137b 100644 --- a/README.md +++ b/README.md @@ -13,13 +13,13 @@ We named the project 'dex' because it is a central index of users that other pie dex consists of multiple components: - **dex-worker** is the primary server component of dex - - host a user-facing API that drives the OIDC protocol + - host a user-facing API that drives the OIDC protocol - proxy to remote identity providers via "connectors" - - provides an API for administrators to manage users. + - provides an API for administrators to manage users. - **dex-overlord** is an auxiliary process responsible for various administrative tasks: - rotation of keys used by the workers to sign identity tokens - garbage collection of stale data in the database - - provides an API for bootstrapping the system. + - provides an API for bootstrapping the system. - **dexctl** is a CLI tool used to manage a dex deployment - configure identity provider connectors - administer OIDC client identities