8b8c076ecf
Now that LDAP supports an `insecureSkipVerify` option, clarify that `insecureNoTLS` is an extremely bad choice and as such we may drop support for 389 in the future. However, since we send plain text passwords from our frontend to our backend, this probably gets us into a bigger conversation about dex's TLS story. For example when terminiation is approporate. cc'ing @dghubble for thoughts on how that might apply to our internal uses. We probably want an overaching security doc at some point, but that can be another PR.
dex - A federated OpenID Connect provider
Dex is an OpenID Connect server that allows users to login through upstream 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.
OpenID Connect is a flavor of OAuth that builds on top of OAuth2 using the JOSE standards. This allows dex to provide:
- 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.
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:
Documentation
- Getting started
- What's new in v2
- Storage options
- Intro to OpenID Connect
- gRPC API
- Identity provider logins
- Client libraries
Getting help
- For bugs and feature requests (including documentation!), file an issue.
- For general discussion about both using and developing dex, join the dex-dev mailing list.
- For more details on dex development plans, check out the GitHub milestones.