Repository navigation
Replies: 4 comments 2 replies
|
Did you try to throw a WebApplicationException(...) with a prebuild Response? |
|
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 |
|
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? |
|
+1 Would like to know this as well. |
|
+1 |
|
I read up on the draft you posted. I don't see how this is meaningfully different to the Resource Owner Password Credentials grant. |
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