[Adding what we discussed] Authorization code flow should not be used as a backchannel API, but rather only as a redirect-based API through the user-agent. That is pretty obvious from the fact that all responses return a Location header. That means that the cookie should always be there as the user is authenticated. id_token_hint should never be used to re-authenticate, but rather only as a hint on the identity of the user as well as the session. If the id_token could be used to actually authenticate the user it would effectively become a user credential and giving a client full access to the user account, with the ability to obtain tokens for any client. prompt=none with id_token_hint can be used as a way to identify if the expected user is still authenticated, but only through a redirect (either directly or with a hidden iframe), not as a backchannel mechanism. On Fri, 25 Oct 2019 at 18:25, Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: > Hi, > > I would like to confirm that we don't support the `id_token_hint` > authorization request parameter. > > When in conjunction with `prompt=none` it is useful to re-authenticate as > well as check whether or not the session associated with the token is > active through a non-authenticated request (e.g.: no cookies set by the > OP). > > The use case I'm trying to solve is based on the assumption that you only > have/keep the ID Token, you don't want a front/back channel for logout > (e.g.: app is stateless), you need to check whether or not session is > active, and the check is done through a backchannel communication between > the application and the OP. > > Spec-wise, using either user-info or introspection endpoint is not > possible > if you only have the ID Token (although some implementations like Google > provide an addition `id_token_hint` to the introspection endpoint) given > that you should use the access token as a bearer. > > Wdyt ? > > Regards. > Pedro Igor > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev >

The sane approach to me is to extend the token introspection endpoint to be able to introspect ID tokens. Extending authorization endpoint with custom responses is just weird ;) On Tue, 29 Oct 2019 at 21:23, Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: > Yes, I was more thinking about re-using the authorization endpoint + > prompt=none + id_token_hint with a custom response to indicate whether or > not the session is active. Similar to what some implementations do by > extending the introspection endpoint or something else. > > On Tue, Oct 29, 2019 at 12:06 PM Stian Thorgersen <sthorger(a)redhat.com&gt; > wrote: > >> [Adding what we discussed] >> >> Authorization code flow should not be used as a backchannel API, but >> rather only as a redirect-based API through the user-agent. That is pretty >> obvious from the fact that all responses return a Location header. That >> means that the cookie should always be there as the user is authenticated. >> >> id_token_hint should never be used to re-authenticate, but rather only >> as a hint on the identity of the user as well as the session. If the >> id_token could be used to actually authenticate the user it would >> effectively become a user credential and giving a client full access to the >> user account, with the ability to obtain tokens for any client. >> >> prompt=none with id_token_hint can be used as a way to identify if the >> expected user is still authenticated, but only through a redirect (either >> directly or with a hidden iframe), not as a backchannel mechanism. >> >> On Fri, 25 Oct 2019 at 18:25, Pedro Igor Silva <psilva(a)redhat.com&gt; >> wrote: >> >>> Hi, >>> >>> I would like to confirm that we don't support the `id_token_hint` >>> authorization request parameter. >>> >>> When in conjunction with `prompt=none` it is useful to re-authenticate >>> as >>> well as check whether or not the session associated with the token is >>> active through a non-authenticated request (e.g.: no cookies set by the >>> OP). >>> >>> The use case I'm trying to solve is based on the assumption that you >>> only >>> have/keep the ID Token, you don't want a front/back channel for logout >>> (e.g.: app is stateless), you need to check whether or not session is >>> active, and the check is done through a backchannel communication >>> between >>> the application and the OP. >>> >>> Spec-wise, using either user-info or introspection endpoint is not >>> possible >>> if you only have the ID Token (although some implementations like Google >>> provide an addition `id_token_hint` to the introspection endpoint) given >>> that you should use the access token as a bearer. >>> >>> Wdyt ? >>> >>> Regards. >>> Pedro Igor >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>