I’m trying to configure a brokered IdP that uses OIDC with Implicit Flow, but I couldn’t figure out how. When creating a new OIDC IdP, the configuration form is based on Authorization Flow. Is it possible to configure Implicit Flow? If not, is it because that flow is deprecated?
Thank you, and I apologize if that was asked before. It’s possible that I missed it, as this is my first day with Keycloak. (Big fan.) I did look through the UI, watched Stian’s awesome introductory video, and searched through the admin and developer doc, but still couldn’t figure it out, so I’m asking here.
Hi @davux, what do you mean by the implicit flow? Do you have already authenticated identity from external IDP and do you want to link/create profile into your KeyCloak? Please elaborate.
I’m at the stage of creating the external IdP in Keycloak. I chose “OpenID Connect v1.0” from the list of provider types, but in the configuration form there are fields such as “client authentication”, “client secret” and “token endpoint” that don’t apply to Implicit Flow but are still mandatory. I don’t see an option to pick which OIDC flow should be used either, so maybe only Authorization Code Flow is supported?
Thanks for asking for clarification. I hope that’s better now.
No worries @davux , you would still need to select client authentication, set it to “JWT signed with private key”, then you’ll see client secret field is no more mandatory.
Thanks for following up, @anand-kulk. What about the “authorization endpoint” field? And more generally, one would need to tell Keycloak to use an Implicit Flow (i.e. response_type=token) with that external provider, correct? I don’t see where that can be configured.
@davux, I am new to Keycloak as well, the way I understood implicit flow is that it doesn’t expose the client secret from browser. But you’ll still need to redirect your browser to authorization endpoint for the authentication(login) from the user, isn’t that correct?
This is a browser-based protocol that is similar to Authorization Code Flow except there are fewer requests and no refresh tokens involved. We do not recommend this flow as there remains the possibility of access tokens being leaked in the browser history as tokens are transmitted via redirect URIs (see below). Also, since this flow doesn’t provide the client with a refresh token, access tokens would either have to be long-lived or users would have to re-authenticate when they expired. This flow is supported because it is in the OIDC and OAuth 2.0 specification. Here’s a brief summary of the protocol:
1. Browser visits application. The application notices the user is not logged in, so it redirects the browser to Keycloak to be authenticated. The application passes along a callback URL (a redirect URL) as a query parameter in this browser redirect that Keycloak will use when it finishes authentication. 2. Keycloak authenticates the user and creates an identity and access token. Keycloak redirects back to the application using the callback URL provided earlier and additionally adding the identity and access tokens as query parameters in the callback URL. 3. The application extracts the identity and access tokens from the callback URL.
Thanks @anand-kulk. I’m interested in using Implicit Flow between Keycloak as the client (as identity broker) and an external IdP. The documentation you’re referring to is for using Implicit Flow between an application as client and Keycloak as IdP.
@davux, wouldn’t your identity broker has its client that invokes the broker? Broker wouldn’t initiate the flow on its own. The implicit flow is specifically for browser based clients.
It’s true that usually Implicit Flow is picked when there’s a limitation of the client (SPAs typically). In my particular case it’s a limitation of the AS, which only supports Implicit Flow (with response_type=form_post which doesn’t leak the tokens).
Because of that limited AS support, I’m trying to have Keycloak use that flow instead of Authorization Flow. I think it’s not possible currently, so I’ll take a look at creating a specific social provider once I get a better understanding of Keycloak’s internals.
@davux, I think you are correct and at this moment it is not possible to use a different flow but Authorization Code flow as the “response_type=code” is hardcoded in AbstractOauth2IdentityProvider.java which is used to create Identity Provider brokers.
In my opinion, this feature should be added to have full compliance with OpenID Connect v1.0 when connecting to an external IdP to use either response_type=id_token or response_type=id_token token using response_mode=form_post.
Please let me know if you found a way of doing this or if your are thinking on extending Keycloak as I’m interested on the topic as well.
I’m trying to use KeyCloak to create a tool provider for LTI 1.3 that is consumed by the Moodle LTI module. The Moodle module acts as an IDP and I want to connect KeyCloak to it. Unfortunately, Moodle only supports the implicit flow.