f778b2d33b
The server implements a strategy called "Refresh Token Rotation" to ensure refresh tokens can only be claimed once. ref: https://tools.ietf.org/html/rfc6819#section-5.2.2.3 Previously "refresh_token" values in token responses where just the ID of the internal refresh object. To implement rotation, when a client redeemed a refresh token, the object would be deleted, a new one created, and the new ID returned as the new "refresh_token". However, this means there was no consistent ID for refresh tokens internally, making things like foreign keys very hard to implement. This is problematic for revocation features like showing all the refresh tokens a user or client has out. This PR updates the "refresh_token" to be an encoded protobuf message, which holds the internal ID and a nonce. When a refresh token is used, the nonce is updated to prevent reuse, but the ID remains the same. Additionally it adds the timestamp of each token's last use. |
||
|---|---|---|
| api | ||
| cmd | ||
| connector | ||
| Documentation | ||
| examples | ||
| scripts | ||
| server | ||
| storage | ||
| vendor | ||
| version | ||
| web | ||
| .gitignore | ||
| .travis.yml | ||
| DCO | ||
| Dockerfile | ||
| glide_test.go | ||
| glide.lock | ||
| glide.yaml | ||
| LICENSE | ||
| Makefile | ||
| README.md | ||
dex - A federated OpenID Connect provider
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.
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:
Kubernetes + dex
Dex's main production use is as an auth-N addon in CoreOS's enterprise Kubernetes solution, 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 and kubectl, can act on behalf 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.
Documentation
- Getting started
- What's new in v2
- Storage options
- Intro to OpenID Connect
- gRPC API
- Using Kubernetes with dex
- 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.