Re: [keycloak-dev] Silent Re-authentication using ID Token

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 >>> >>