3:55 p.m.
Hello Seán, welcome on board :)
Yes, what you want is doable, however with a few customizations. The "theory"
here is that different flows (authorization code / implicit / hybrid) are triggered by
different incoming response_type param values [2], and this param is exposed to Keycloak
authentication layer. However, token generation happens at a different layer, and
you'll need to bridge them together.
- run Keycloak with -Dkeycloak.profile=preview or
-Dkeycloak.profile.feature.script=enabled [1];
- in your browser flow, create a script authenticator. Its authenticate() method body
should consist only of a couple of lines:
var response_type = authenticationSession.clientNotes.response_type;
authenticationSession.setUserSessionNote("response_type", response_type);
context.success();
- go to client settings -> Mappers, create a User Session Note mapper and map
"response_type" note into a claim. Your application will need analyze this claim
and make an allow/deny decision;
- alternatively, you can craft a more sophisticated JS mapper that would look into
response_type and infer flow type from it, putting it into a custom claim.
Let me know if you have any further questions.
[1] https://www.keycloak.org/docs/latest/server_installation/index.html#profiles
[2] https://openid.net/specs/openid-connect-core-1_0.html#Authentication
Good luck,
Dmitry Telegin
Carretti Consulting OÜ | Keycloak Consulting and Training
Sepapaja 6, Tallinn 15551, Estonia | info(a)carretti.pro
On Fri, 2019-06-28 at 09:18 +0100, Seán Kelleher wrote:
Hi everyone,
This is my first time using this service, so apologies if I've overlooked a
precondition for posting.
Is there a way to retrieve or derive the grant that was used to obtain a
particular access token, from the access token itself?
My use case is that I have an `/accept_tos` endpoint that takes an IP
address, which is logged as having accepted our terms of service. This is
under the assumption that the endpoint is being called by a client
application that authenticated the user using an authorization code grant.
However, we now also support logins using the implicit flow, so the
acceptance request is no longer being relayed by a third party client, but
is instead being made by the client itself. In this case I want the app to
use `/accept_tos_direct`, which will use the IP address of the request
itself (accounting for reverse proxies) instead of taking it from the body
of the request. Of course, a client could try and determine its own IP
address and supply that using `/accept_tos`, but I feel like this is a
slightly hacky workaround and may lend itself to error.
I want to be able to prevent clients from using the wrong endpoint, based
on the grant they used to retrieve their access token. At the moment, I
don't see any fields in the access token that can be used to get this
information, or how I could enable such a field. I thought the "aud" field
could fit the purpose, assuming that it was something like "<client_id>"
in
the case of an authorization code grant and something like
"resource_server" in the case of an implicit grant, but when I tested this
assumption, access tokens from both grants gave a value of
`["<client_id>",
"account"]`. Does anyone have any suggestions as to how I could get this
behaviour?
Kind regards,
Seán.
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user