Feature: support OIDC implicit flow

[ericchiang]

see #255

[chris-rock]

+1 on implicit flow, although not all connectors will be able to implement this. Therefore it depends on the connector to allow this flow

[sym3tri]

I just want to note that implicit flow does come at a cost b/c it is a less secure auth flow. If we implement we should consider putting behind a config flag.

[chris-rock]

The use case I have: Use dex auth from my cli applications. In that case you have two choices:

• api token
• implicit flow

Have I missed a way?

[ericchiang]

Implicit flow is for clients who can't hide their client_secret (e.g. frontend only applications).

OAuth2 / OpenID Connect are intended to be for browser based apps, but for CLI tools a setup could go like this:

• Assign the CLI a client_id and client_secret and register a redirect for http://localhost:8888/redirect or something
• cli login should do two things:
  • Begin listening for the oauth2 redirect on http://localhost:8888/redirect
  • Generate a redirect URL using the client_id for the user to paste into a web browser.
• Once the user logs into dex, the browser will hit http://localhost:8888/redirect with a code.
• The CLI tool uses that code with it's client_id and client_secret to request an OAuth2 token from dex then parses out the OpenID Connect ID Token.
• Use that ID Token to make requests with your CLI.

You could get fancier if your client requests refresh tokens.

Does this make sense?

[chris-rock]

@ericchiang Oh yeah, that works as well. The only challenge that I see with this approach is that it does break the user flow and it does not work well via ssh on servers. I still agree that tokens are more secure then user credentials.

[ericchiang]

Correct me if I'm wrong but I think you're referring to the "Resource Owner Password Grants" (grant_type=password), not the implicit flow.

https://tools.ietf.org/html/rfc6749#section-4.3

I don't believe OpenID Connect allows this grant type.

[blingwang]

+1 on implicit flow. I really need the implicit flow to get my Angular app to work with dex. There's no safe way to store my client id and secret in the Angular app. SPAs like Angular apps are very popular these days. I believe the implicit flow will benefit a lot of people.

[ericchiang]

This is now supported by dex, though we need to add a documentation for how to turn this on.

[aryzle]

@ericchiang where is the documentation for turning on implicit flow?

[rithujohn191]

@aryzle we don't have specific documentation for it. But the comments in the code point you in the right direction. Was there something specific you were looking for?

[aryzle]

@rithujohn191 I've tried setting supportedResponseTypes: ["token", "id_token"] and SupportedResponseTypes: ["token", "id_token"] in the config yml file but dex still shows me "code" as the only response type

I was specifically looking for documentation on configuring dex to support implicit flow for the OIDC spec

[ericchiang]

@aryzle this is config field

oauth2:
  responseTypes: ["code", "token", "id_token"]

But you're right, we don't document this. Will send a PR to do so.

[rithujohn191]

Fixed in #980

[aryzle]

👍 thanks!