You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Refactoring Authenticators to Support an API-Based Authentication Approach
#36924
This discussion follows the previous discussion: Support for native login experiences with OAuth 2.0 First-Party Applications (FiPA) #25014. So far, I have aimed to keep the topics separate.
In order to support OAuth 2.0 FiPA, which follows an API-based approach, it would be helpful to start decoupling the response type from authenticators. So far, due to the support of OIDC/OAuth with the traditional redirect model, responses have been tied to forms. Decoupling will also help avoid duplicate code, as the core functionality of the authenticator remains the same regardless of the authentication flow (web or API)
Perhaps by adopting a similar approach and moving this method to the Authenticator interface, each authenticator could handle its own response type. Something like this:
Hi @thomasdarimont, thanks for the feedback. I haven't tried it yet, but I believe I also need to decouple the response type from the authenticate method. For instance, right now, everything is tied to the LoginFormsProvider, which finally is FreeMarkerLoginFormsProvider. In the case of FiPA, I need to be able to return a JSON response with the metadata about the authenticator. I'm trying to avoid duplicating the code in the authenticate method just to have a different error response.
Hello, do I understand correctly that until this change is developed, it is not possible to implement fully mobile native auth using Keycloak? I mean authentication without using a browser popup?
I read up on the draft you posted. I don't see how this is meaningfully different to the Resource Owner Password Credentials grant.
I don't believe that this draft will be accepted. It goes against the idea that the Authorization Code Grant implicitly authenticates the user. Having the client do that flow would mean this would become mere impersonation again. Which we already have ROPC for.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
This discussion follows the previous discussion: Support for native login experiences with OAuth 2.0 First-Party Applications (FiPA) #25014. So far, I have aimed to keep the topics separate.
In order to support OAuth 2.0 FiPA, which follows an API-based approach, it would be helpful to start decoupling the response type from authenticators. So far, due to the support of OIDC/OAuth with the traditional redirect model, responses have been tied to forms. Decoupling will also help avoid duplicate code, as the core functionality of the authenticator remains the same regardless of the authentication flow (web or API)
As a possible approach, for instance, the WebAuthnAuthenticator has the
setErrorResponsemethod, which allows handling error responses.https://github.com/keycloak/keycloak/blob/main/services/src/main/java/org/keycloak/authentication/authenticators/browser/WebAuthnAuthenticator.java#L269.
Perhaps by adopting a similar approach and moving this method to the Authenticator interface, each authenticator could handle its own response type. Something like this:
This way, the NativeAuthenticator that supports challenge error response will have something like this:
Meanwhile, the traditional authenticator will continue handling the form response.
The goal of this discussion is to evaluate whether this kind of change can be introduced to the platform.
Feedback and comments are very welcome.
Reference:
[1] https://www.ietf.org/archive/id/draft-ietf-oauth-first-party-apps-00.html
[2] Discussion: Support OAuth 2.0 First-Party Applications (FiPA) #25014.
[3] https://medium.com/@embesozzi/deep-dive-into-enhancing-user-experience-with-native-authentication-and-passkeys-in-keycloak-86fb72c64278
All reactions
Replies: 4 comments · 2 replies
Uh oh!
There was an error while loading. Please reload this page.
Did you try to throw a WebApplicationException(...) with a prebuild Response?
All reactions
Uh oh!
There was an error while loading. Please reload this page.
Hi @thomasdarimont, thanks for the feedback. I haven't tried it yet, but I believe I also need to decouple the response type from the authenticate method. For instance, right now, everything is tied to the LoginFormsProvider, which finally is
FreeMarkerLoginFormsProvider. In the case of FiPA, I need to be able to return a JSON response with the metadata about the authenticator. I'm trying to avoid duplicating the code in the authenticate method just to have a different error response.All reactions
Uh oh!
There was an error while loading. Please reload this page.
Hello, do I understand correctly that until this change is developed, it is not possible to implement fully mobile native auth using Keycloak? I mean authentication without using a browser popup?
All reactions
Uh oh!
There was an error while loading. Please reload this page.
+1 Would like to know this as well.
All reactions
Uh oh!
There was an error while loading. Please reload this page.
+1
Would be great if an update on the issue could be provided. I assume the interest in the community is huge on this feature.
All reactions
Uh oh!
There was an error while loading. Please reload this page.
I read up on the draft you posted. I don't see how this is meaningfully different to the Resource Owner Password Credentials grant.
I don't believe that this draft will be accepted. It goes against the idea that the Authorization Code Grant implicitly authenticates the user. Having the client do that flow would mean this would become mere impersonation again. Which we already have ROPC for.
All reactions