@@ -138,6 +138,8 @@ A more thorough discussion of these kinds of best practices can be found in the
Apps can also choose to consume ID tokens, letting other trusted clients handle the web flows for login. Clients pass along the ID tokens they receive from dex, usually as a bearer token, letting them act at the user to the backend service.
![][dex-backend-flow]
To accept ID tokens as user credentials, an app would construct an OpenID Connect verifier similarly to the above example. The verifier validates the ID token's signature, ensures it hasn't expired, etc. An important part of this code is that the verifier only trusts the example app's client. This ensures the example app is the one who's using the ID token, and not another, untrusted client.
Dex is an OpenID Connect server that connects to other identity providers. Clients use a standards-based OAuth2 flow to login users, while the actual authentication is performed by established user management systems such as Google, GitHub, FreeIPA, etc.
Dex is an identity service that uses [OpenID Connect][openid-connect] to drive authentication for other apps.
[OpenID Connect][openid-connect] is a flavor of OAuth that builds on top of OAuth2 using the JOSE standards. This allows dex to provide:
Dex is NOT a user-management system, but 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.
* Short-lived, signed tokens with standard fields (such as email) issued on behalf of users.
* "well-known" discovery of OAuth2 endpoints.
* OAuth2 mechanisms such as refresh tokens and revocation for long term access.
* Automatic signing key rotation.
## ID Tokens
Standards-based token responses allows applications to interact with any OpenID Connect server instead of writing backend specific "access_token" dances. Systems that can already consume ID Tokens issued by dex include:
ID Tokens are an OAuth2 extension introduced by OpenID Connect and dex's primary feature. ID Tokens are [JSON Web Tokens][jwt-io] (JWTs) signed by dex and returned as part of the OAuth2 response that attest to the end user's identity. An example JWT might look like:
ID Tokens contains standard claims assert which client app logged the user in, when the token expires, and the identity of the user.
```json
{
"iss":"http://127.0.0.1:5556/dex",
"sub":"CgcyMzQyNzQ5EgZnaXRodWI",
"aud":"example-app",
"exp":1492882042,
"iat":1492795642,
"at_hash":"bi96gOXZShvlWYtal9Eqiw",
"email":"jane.doe@coreos.com",
"email_verified":true,
"groups":[
"admins",
"developers"
],
"name":"Jane Doe"
}
```
Because these tokens are signed by dex and [contain standard-based claims][standard-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][kubernetes]
*[AWS STS][aws-sts]
For details on how to request or validate an ID Token, see [_"Writing apps that use dex"_][using-dex].
## Kubernetes + dex
Dex's main production use is as an auth-N addon in CoreOS's enterprise Kubernetes solution, [Tectonic][tectonic]. Dex runs natively on top of any Kubernetes cluster using Third Party Resources and can drive API server authentication through the OpenID Connect plugin. Clients, such as the [Tectonic Console][tectonic-console] and `kubectl`, can act on behalf users who can login to the cluster through any identity provider dex supports.
...
...
@@ -29,11 +54,11 @@ More docs for running dex as a Kubernetes authenticator can be found [here](Docu
