Flow example - implicit flow

[zarkoc]

Hi all,

Im trying to implement a client using the Implicit flow.
But the question is also more general, I cant find how and where to set up the response_type so that I can change the flow to implicit.

To me its seems that the default flow is the authorization_code flow.

Thanks,
Zarko

[zarkoc]

As far as I can see we can't modify the responce_type from code?
The relyingParty struct is using oauthConfig *oauth2.Config, which comes from the oauth2 module, and the code responce_type is hardcoded there.
https://cs.opensource.google/go/x/oauth2/+/6b3c2da3:oauth2.go;l=154

But the readme.md in the Features section explicitly mentions that is supports the ImplicitFlow for RP, so I guess Im missing something?

Thanks,
Zarko

[fforootd]

Hi there let me check this tomorrow 😎

cc @livio-a @fgerschwiler

[livio-a]

Hey @zarkoc

First of all: Thanks for the issue.
There seems to be an error in the readme. As you mentioned, we use the oauth2 module which does not support the implicit flow.

Is there any reason why you need to use the implicit flow?

Because IMHO there is no need to support it. The implicit grant was designed for OAuth public clients, which were not able to store a secret. So as a confidential web application there's no need to use it. For various security reasons OAuth2 best current practice proposes to use PKCE instead and OAuth 2.1 will drop it from the specs.

[Azmisov]

I'm looking at Facebook's OIDC support here: https://www.facebook.com/.well-known/openid-configuration... their so called "limited login". Appears to only support the implicit id_token response type however.

@livio-a When you say "there is no need to support it [the implicit flow]", are you implying there is another way to handle auth to a service like Facebook OIDC from our end? If so, what would you recommend? Or were you implying that a provider not supporting the code response_type would never occur in practice?

[muhlemmer]

Implicit only makes sense in certain Single Page Apps running in browsers, where the app can't or won't call the token endpoint using the code in the redirect URL. As this is a Go library, the client always runs in a server context and it is always possible to call the token endpoint. Implicit is also considered less secure as code flow. Hence, we did not see the need.

If there are mayor vendors that only support implicit, we might reconsider based on popular demand of the zitadel and /or oidc community. Technically speaking one should write to Facebook and kindly ask them to support code flow instead, given the above reasoning that seems to be more sane.