* Added /device/token handler with associated business logic and storage tests.
Perform user code exchange, flag the device code as complete.
Moved device handler code into its own file for cleanliness. Cleanup
* Removed PKCE code
* Rate limiting for /device/token endpoint based on ietf standards
* Configurable Device expiry
Signed-off-by: justin-slowik <justin.slowik@thermofisher.com>
* Added /device/token handler with associated business logic and storage tests.
* Use crypto rand for user code
Signed-off-by: justin-slowik <justin.slowik@thermofisher.com>
Co-authored-by: Yuxing Li <360983+jackielii@users.noreply.github.com>
Co-authored-by: Francisco Santiago <1737357+fjbsantiago@users.noreply.github.com>
connector/microsoft implements authorization strategy via Microsoft's
OAuth2 endpoint + Graph API. It allows to choose what kind of tenants
are allowed to authenticate in Dex via Microsoft:
* common - both personal and business/school accounts
* organizations - only business/school accounts
* consumers - only personal accounts
* <tenant uuid> - only account of specific tenant
Signed-off-by: Pavel Borzenkov <pavel.borzenkov@gmail.com>
This allows users of the LDAP connector to give users of Dex' login
prompt an idea of what they should enter for a username.
Before, irregardless of how the LDAP connector was set up, the prompt
was
Username
[_________________]
Password
[_________________]
Now, this is configurable, and can be used to say "MyCorp SSO Login" if
that's what it is.
If it's not configured, it will default to "Username".
For the passwordDB connector (local users), it is set to "Email
Address", since this is what it uses.
Signed-off-by: Stephan Renatus <srenatus@chef.io>
connector/linkedin implements authorization strategy via LinkedIn's
OAuth2 endpoint + profile API.
It doesn't implement RefreshConnector as LinkedIn doesn't provide any
refresh token at all (https://developer.linkedin.com/docs/oauth2, Step 5
— Refresh your Access Tokens) and recommends ordinary AuthCode exchange
flow when token refresh is required.
Signed-off-by: Pavel Borzenkov <pavel.borzenkov@gmail.com>
The bcrypt hashing algorithm runtime grows exponentially with cost,
and might cause a timeout if the cost is too high. Notifying the user
of high cost and of long running calculations will help with tuning
and debugging.
Accept the following response_type for the implicit flow:
id_token
token id_token
And the following for hybrid flow
code id_token
code token
code token id_token
This corrects the previous behavior of the implicit flow, which
only accepted "token" (now correctly rejected).
This PR reworks the web layout so static files can be provided and
a "themes" directory to allow a certain degree of control over logos,
styles, etc.
This PR does NOT add general support for frontend customization,
only enough to allow us to start exploring theming internally.
The dex binary also must now be run from the root directory since
templates are no longer "compiled into" the binary.
The docker image has been updated with frontend assets.
Instead of throwing a 500 error if a user enters an invalid name,
display the same text box as if the user had entered the wrong
password.
NOTE: An invalid username now returns much quicker than an invalid
password. Consider adding an arbitrary sleep in the future if we
care about masking which was invalid.
Let the server handle the state token instead of the connector. As a
result it can throw out bad requests earlier. It can also use that
token to determine which connector was used to generate the request
allowing all connectors to share the same callback URL.
Callbacks now all look like:
https://dex.example.com/callback
Instead of:
https://dex.example.com/callback/(connector id)
Even when multiple connectors are being used.
